diff --git a/docs/security-posture-workflow.md b/docs/security-posture-workflow.md
new file mode 100644
index 0000000..28828af
--- /dev/null
+++ b/docs/security-posture-workflow.md
@@ -0,0 +1,402 @@
+# Security Posture Workflow — Host Finding Review & Remediation
+
+**Document Type:** Process Guide
+**Applies To:** STEAM Security Dashboard — All Pages
+**Audience:** NTS-AEO-STEAM / NTS-AEO-ACCESS-ENG team members
+**Last Updated:** 2026-03-27
+
+---
+
+## Table of Contents
+
+1. [Overview](#1-overview)
+2. [Dashboard Orientation](#2-dashboard-orientation)
+3. [Vulnerability Designations](#3-vulnerability-designations)
+4. [The Host Finding Review Workflow](#4-the-host-finding-review-workflow)
+   - [Step 1 — Sync and Sort by Due Date](#step-1--sync-and-sort-by-due-date)
+   - [Step 2 — Identify the Host](#step-2--identify-the-host)
+   - [Step 3 — Identify Asset Ownership](#step-3--identify-asset-ownership)
+   - [Step 4 — Review the CVEs in the Finding](#step-4--review-the-cves-in-the-finding)
+   - [Step 5 — Determine and Execute the Required Action](#step-5--determine-and-execute-the-required-action)
+5. [Using the Ivanti Queue](#5-using-the-ivanti-queue)
+6. [Workflow Status Reference](#6-workflow-status-reference)
+7. [Quick Reference Card](#7-quick-reference-card)
+
+---
+
+## 1. Overview
+
+The STEAM Security Dashboard centralises vulnerability management for the NTS-AEO-STEAM and NTS-AEO-ACCESS-ENG business units. It pulls host findings directly from Ivanti/RiskSense and gives the team a single place to triage, track, and action every open vulnerability.
+
+**Scope:** This document covers severity findings in the **8.5 – 9.9 VRR range**. All findings in this range require some form of documented action. A finding that is not actioned before its Due Date results in the device being recorded as non-compliant.
+
+> **SLA Rule:** By default, all vulnerabilities must have an action taken or in-flight within **60 days of detection**. The Due Date column on the Reporting page shows the exact deadline. Metrics and compliance reporting are based on vulnerabilities aged under 60 days.
+
+---
+
+## 2. Dashboard Orientation
+
+### Pages
+
+| Page | Purpose |
+|------|---------|
+| **Home (CVE Management)** | Track and research individual CVEs across vendors. Store supporting documentation. Log Archer EXC ticket numbers against CVE/vendor pairs. |
+| **Reporting (Host Findings)** | The primary operational page. Live view of all open Ivanti findings with filtering, sorting, inline editing, the Ivanti Queue, and export. |
+| **Knowledge Base** | Internal document library — policies, runbooks, vendor advisories. |
+| **Exports** | Bulk export tools for reports and data extracts. |
+
+### Reporting Page — At a Glance
+
+When you open the Reporting page for the first time in a session, click **Sync** (top right) to pull the latest findings from Ivanti. The page shows:
+
+- **Four metric charts** at the top — Open vs Closed, Action Coverage, FP Finding Status, FP Workflow Status
+- **Findings table** below — every open finding for the configured BUs, one row per host finding
+- **Ivanti Queue panel** (click the Queue button, top right) — your personal staging list for batch-processing FP and Archer workflows
+
+The charts and table update together. Clicking a chart segment filters the table to that subset.
+
+---
+
+## 3. Vulnerability Designations
+
+Every finding in the 8.5–9.9 range requires one of three documented actions. Understanding these upfront makes triage faster.
+
+### 3.1 Remediation
+
+The vulnerability is addressed by fixing the root cause.
+
+| Remediation Method | Archer Ticket Required? | Notes |
+|---|---|---|
+| Firmware or software update | **No** | Upgrading removes the vulnerability entirely. The finding will fall off the report on the next scan. |
+| Configuration change | **Yes** | A config change does not remove the vulnerability — if the config is ever rolled back, the vulnerability returns. An Archer Risk Acceptance ticket is required to document this. |
+
+### 3.2 False Positive (FP)
+
+A false positive occurs when the scanner detects a vulnerability that is **not actually present** or **does not apply** to the platform or software version in use.
+
+**An FP workflow must be opened in Ivanti.** The workflow requires:
+
+1. A **screenshot** taken directly from the device showing:
+   - Hostname
+   - IP address
+   - Software / firmware version
+   > **Important:** This must be a screenshot. CLI text output or copy-pasted command output is not accepted.
+
+2. **Vendor documentation** confirming the vulnerability does not affect the platform — one of:
+   - Direct vendor communication (email, support ticket)
+   - Published security advisory stating the version or platform is not affected
+   - Proof that the vulnerability does not apply to the currently installed version
+
+Supporting files (screenshots, emails, advisories) should be saved into the CVE Database (Home page → upload documents against the relevant CVE/vendor pair) for future reference and re-use if the FP expires and needs to be renewed.
+
+### 3.3 Risk Acceptance / Archer Request
+
+An Archer Risk Acceptance ticket (EXC-XXXXX) is required when a vulnerability **cannot be patched** for a documented business or technical reason. Common scenarios:
+
+| Scenario | Required Action |
+|---|---|
+| Patch not yet available (waiting on vendor) | Open Archer ticket; close it when patch is deployed |
+| Device is End-of-Sale (EOS) or End-of-Life (EOL) | Archer ticket required with mitigation steps and a remediation plan |
+| Business constraint prevents patching | Archer ticket with justification and compensating controls |
+| Configuration-change-only remediation | Archer ticket required (see Remediation above) |
+
+For EOL/EOS devices the ticket must include:
+- Current mitigation steps (network segmentation, compensating controls)
+- A remediation plan — what will replace or retire the device and when
+
+If vendor communication is needed (patch timeline, configuration guidance), open a vendor support ticket and use the vendor's response to fill out the Archer remediation plan field.
+
+> Archer EXC numbers are tracked in the dashboard. Once entered on the Home page against the relevant CVE/vendor pair, the EXC badge appears on that CVE row. Clicking the badge navigates to the Reporting page pre-filtered to findings with that EXC number in their notes.
+
+---
+
+## 4. The Host Finding Review Workflow
+
+Work through the Reporting page top-to-bottom by Due Date. The goal of each session is to ensure every finding either has an action in-flight or gets one started.
+
+---
+
+### Step 1 — Sync and Sort by Due Date
+
+1. Navigate to the **Reporting** page.
+2. Click **Sync** (top right). Wait for the sync to complete — the timestamp updates when done.
+3. Click the **Due Date** column header to sort ascending (soonest due date first).
+   - Red due dates = overdue
+   - Amber due dates = due within 30 days
+   - Start with red, then amber
+
+> If you want to focus on findings with no action yet, click the **Pending** segment on the Action Coverage donut chart. The table will filter to only findings with no FP ticket and no EXC number in notes.
+
+---
+
+### Step 2 — Identify the Host
+
+Each finding row includes a **Host** (hostname), **IP Address**, and **DNS** column.
+
+1. Use the reported **IP address** to verify the hostname in:
+   - **IPControl** (read-only, historical IPAM data)
+   - **Infoblox** (current IPAM — preferred for current state)
+
+2. If the hostname shown in the dashboard is incorrect (Ivanti sometimes reports stale data):
+   - Click the **Host** cell in the finding row — it is inline editable.
+   - Type the correct hostname and press **Enter** or click away to save.
+   - An amber dot (●) will appear on the cell to indicate an override is in place. The original Ivanti value is preserved and can be restored using the revert button (↻).
+   - The same applies to the **DNS** column.
+
+> Overrides survive Ivanti re-syncs — your corrections are not overwritten when new data is pulled.
+
+---
+
+### Step 3 — Identify Asset Ownership
+
+Check the **BU** column to determine ownership.
+
+| BU Value | Ownership | Action |
+|---|---|---|
+| `NTS-AEO-STEAM` | Our team | Continue to Step 4 |
+| `NTS-AEO-ACCESS-ENG` | Our team | Continue to Step 4 |
+| Any other value, or blank | Not our asset | Add to CARD queue (see below) |
+
+**If the asset is not owned by our BU:**
+
+1. Check the checkbox at the left of the finding row.
+2. A popover will appear. The **CARD** workflow type should already be selected.
+   - No vendor entry is required for CARD — the IP address is captured automatically for use when searching in CARD.
+3. Click **Add to Queue**.
+4. The finding is now staged in your Ivanti Queue under the **CARD** section.
+
+CARD queue items are processed in a separate session — see the [Ivanti Queue](#5-using-the-ivanti-queue) section and the dedicated CARD process documentation.
+
+---
+
+### Step 4 — Review the CVEs in the Finding
+
+Each finding has one or more CVEs listed in the **CVEs** column (up to 2 shown; hover the "+N" badge to see the rest).
+
+For each CVE in the finding:
+
+1. **Check if the CVE already exists in the database.**
+   - Navigate to the **Home** page.
+   - Search for the CVE ID in the search bar.
+   - If an entry exists for this CVE and vendor, review what's already documented — there may be existing notes, documents, or an Archer ticket already linked.
+
+2. **If no entry exists, create one:**
+   - Click **Add CVE** on the Home page.
+   - Enter the CVE ID — the NVD auto-fill will populate the description, CVSS severity, and published date automatically.
+   - Select the correct vendor/platform.
+   - Save the entry.
+
+3. **Research the CVE** to determine the required action:
+   - Check the vendor's security advisory portal (e.g., Juniper Security Advisories, Cisco Security Advisories / Bug Search Tool)
+   - Determine whether the CVE: (a) is a False Positive for this platform/version, (b) can be Remediated, or (c) requires a Risk Acceptance
+
+---
+
+### Step 5 — Determine and Execute the Required Action
+
+Based on your research in Step 4, choose the path below.
+
+---
+
+#### Path A — Remediation (Firmware or Software Update)
+
+> No Archer ticket required if the fix is a firmware or software upgrade.
+
+1. Plan and schedule the upgrade with the relevant team.
+2. No dashboard action is required beyond ensuring a note is added to the finding (click the **Notes** cell) confirming the upgrade is planned or complete.
+3. After the device is upgraded, the finding will fall off the Reporting page on the next Ivanti scan if the vulnerability is no longer detected.
+
+---
+
+#### Path B — Remediation (Configuration Change)
+
+> An Archer Risk Acceptance ticket **is required** when the fix is a configuration change.
+
+1. Check the checkbox at the left of the finding row.
+2. In the popover, enter the **Vendor / Platform** (e.g., Juniper, Cisco, ADTRAN).
+3. Select **Archer** as the workflow type.
+4. Click **Add to Queue**.
+5. Process the Archer ticket in a dedicated session — see [Ivanti Queue](#5-using-the-ivanti-queue) and the Archer process documentation.
+
+---
+
+#### Path C — False Positive
+
+1. **Collect the required evidence:**
+   - Log into the device and **take a screenshot** showing the hostname, IP address, and software/firmware version.
+   - Obtain vendor documentation confirming the CVE does not affect this platform or version (security advisory, vendor email, etc.).
+
+2. **Save supporting files to the database:**
+   - Go to the Home page and find (or create) the CVE entry for this vendor.
+   - Upload the screenshot as type `screenshot` and the vendor communication as type `advisory` or `email`.
+   - This ensures the evidence is accessible when the FP expires and needs to be renewed.
+
+3. **Stage the finding in the queue:**
+   - Check the checkbox at the left of the finding row on the Reporting page.
+   - Enter the **Vendor / Platform**.
+   - Select **FP** as the workflow type.
+   - Click **Add to Queue**.
+
+4. **Open the False Positive workflow in Ivanti:**
+   - Process queued FP items in a dedicated session.
+   - See the dedicated FP workflow documentation for the full Ivanti submission steps.
+
+---
+
+#### Path D — Risk Acceptance (Archer Ticket)
+
+1. **Collect information** as you would for a False Positive (device screenshot, version info).
+2. If vendor communication is required (patch timeline, EOL statement, recommended mitigations):
+   - Open a vendor support ticket requesting remediation steps, configuration guidance, or a patch commitment date.
+   - Use the vendor's response to fill out the Archer remediation plan.
+3. **Stage the finding in the queue:**
+   - Check the checkbox on the finding row.
+   - Enter the **Vendor / Platform**.
+   - Select **Archer** as the workflow type.
+   - Click **Add to Queue**.
+4. **Open the Archer Risk Acceptance ticket:**
+   - Process queued Archer items in a dedicated session.
+   - See the dedicated Archer process documentation for the full submission steps.
+5. Once the EXC number is assigned, enter it in the finding's **Notes** cell on the Reporting page (format: `EXC-XXXXX`). The dashboard will recognise the pattern and include it in the Action Coverage chart under "Archer Exception".
+
+---
+
+## 5. Using the Ivanti Queue
+
+The Ivanti Queue is a personal staging list built into the Reporting page. Rather than interrupting your review to context-switch into Ivanti, you tag findings as you go and then batch-process all the Ivanti work in one focused session.
+
+### Adding Items to the Queue
+
+1. On the Reporting page, check the **checkbox at the far left** of any finding row.
+2. A popover appears anchored to the row.
+3. For **FP** and **Archer** items: enter the **Vendor / Platform** (free text — e.g., "Juniper MX", "Cisco IOS-XE").
+4. Select the **workflow type**:
+   - **FP** — False Positive request to be submitted in Ivanti
+   - **Archer** — Archer Risk Acceptance ticket to be opened
+   - **CARD** — Asset not owned by our BU; IP address is captured automatically
+5. Click **Add to Queue**. The row checkbox turns solid blue to indicate it is queued.
+
+### Opening the Queue Panel
+
+Click the **Queue** button in the top-right of the Reporting page. A slide-out panel opens from the right showing all your queued items.
+
+- **CARD** items appear at the top of the panel in their own green section, with the IP address displayed for easy CARD search.
+- **FP and Archer** items are grouped alphabetically by vendor/platform below.
+- Each item shows: Finding ID, CVEs (or IP for CARD), and the workflow type badge (amber = FP, sky = Archer, green = CARD).
+
+### Working the Queue
+
+**Marking items complete:**
+Once you have submitted the FP or Archer ticket in Ivanti (or actioned the CARD item), check the item's green checkbox to mark it complete. Completed items are shown with a strikethrough at reduced opacity.
+
+**Deleting items:**
+- Click the trash icon on an individual item to remove it.
+- To remove multiple items at once: check the small red selection checkbox on the left of each item you want to remove, then click **Delete (N)** in the footer.
+
+**Clearing completed items:**
+Click **Clear Completed** in the footer to remove all marked-complete items at once.
+
+> Queue items are stored in the database and are **personal to your login** — they persist across sessions and page refreshes. Other team members see only their own queue.
+
+---
+
+## 6. Workflow Status Reference
+
+The **Workflow** column on the Reporting page tracks FP# tickets — False Positive requests submitted in Ivanti. The badge shows the ticket ID and its current state, colour-coded by urgency.
+
+> SYS# workflows are auto-generated system tracking records. They are not displayed and do not require team action.
+
+### Status Colour Codes
+
+#### 🔴 Red — Act Immediately
+
+| State | Meaning | Required Action |
+|---|---|---|
+| **Expired** | An FP# ticket existed but the exception window has lapsed. The finding has re-opened. | Log into Ivanti and submit a **new FP request** for this finding. Reference the previous ticket if relevant. |
+| **Rejected** | The security team reviewed the FP and denied it. The finding is a confirmed, exploitable vulnerability. | **Remediate the vulnerability.** Apply the relevant patch, configuration change, or compensating control. Do not resubmit an FP without new evidence. |
+
+#### 🟡 Amber — Action Required Soon
+
+| State | Meaning | Required Action |
+|---|---|---|
+| **Reworked** | The FP request was challenged by the reviewer and returned for revision. | Open the ticket in Ivanti, review the feedback, update the justification, and **resubmit**. |
+| **Actionable** | The FP ticket has been flagged as needing team action. | Open the ticket in Ivanti and respond to what is required. |
+
+#### 🔵 Blue — In Flight, Monitor
+
+| State | Meaning | Required Action |
+|---|---|---|
+| **Requested** | An FP# ticket has been submitted and is awaiting security team approval. | No immediate action. Monitor for approval or rejection. If the SLA window is approaching with no response, follow up with the approver. |
+
+#### — (No Badge) — Untriaged
+
+| State | Meaning | Required Action |
+|---|---|---|
+| **No workflow badge** | No FP ticket has ever been submitted for this finding. | Triage the finding using the workflow in Section 4. Determine whether to remediate, submit an FP, or open an Archer ticket. |
+
+### Decision Flowchart
+
+```
+Finding appears in Reporting page
+│
+├── Check the Workflow column
+│
+├── No badge (—)
+│   └── Triage → follow Section 4 workflow
+│
+└── Has a badge → check the colour:
+    │
+    ├── 🔵 BLUE (Requested)
+    │   └── Monitor. Follow up if SLA window is approaching.
+    │
+    ├── 🟡 AMBER (Reworked / Actionable)
+    │   └── Open Ivanti ticket → review feedback → update → resubmit
+    │
+    └── 🔴 RED
+        │
+        ├── Expired → Submit a new FP request in Ivanti
+        │
+        └── Rejected → Remediate the vulnerability
+```
+
+---
+
+## 7. Quick Reference Card
+
+### Action Decision Matrix
+
+| Research Outcome | Config Change? | Action Required |
+|---|---|---|
+| Can be patched (firmware/software) | N/A | Upgrade device — no ticket needed |
+| Can be patched (configuration change only) | Yes | Archer Risk Acceptance ticket (EXC-XXXXX) |
+| False Positive — not applicable to platform/version | N/A | FP workflow in Ivanti + evidence in CVE database |
+| Cannot be patched — patch pending from vendor | N/A | Archer Risk Acceptance ticket (renew when patched) |
+| Cannot be patched — EOL/EOS device | N/A | Archer ticket with mitigation steps + remediation plan |
+| Asset not owned by our BU | N/A | CARD queue → CARD asset disposition process |
+
+### Workflow Badge Quick Reference
+
+| Badge | State | One-Line Action |
+|---|---|---|
+| 🔴 Red | Expired | Renew FP request in Ivanti |
+| 🔴 Red | Rejected | Remediate the vulnerability |
+| 🟡 Amber | Reworked | Update and resubmit FP ticket |
+| 🟡 Amber | Actionable | Review ticket in Ivanti and respond |
+| 🔵 Blue | Requested | Monitor — no action yet |
+| — | No badge | Triage: follow Section 4 |
+
+### Dashboard Shortcut Reference
+
+| Task | How |
+|---|---|
+| See only untriaged findings | Click **Pending** segment on Action Coverage chart |
+| See findings due this week | Click a date on the Home page calendar widget |
+| See all findings for a specific Archer ticket | Click the EXC badge on the Home page CVE row |
+| Correct a wrong hostname | Click the Host cell inline on the Reporting page |
+| Save a screenshot or advisory to a CVE | Home page → CVE row → Upload document |
+| Stage findings for a batch FP/Archer session | Use the Ivanti Queue (checkbox column on Reporting page) |
+| Filter to a specific vendor or SLA status | Click the filter icon (⊙) on the relevant column header |
+
+---
+
+*Related documentation: FP Workflow Submission (Ivanti) · Archer Risk Acceptance Process · CARD Asset Disposition Process · MOP: Workflow Status Colour Codes*