Use Case

Cross-engagement finding search
and cohort assembly across every client and project

Assemble vulnerability cohorts across every engagement, every client, and every scan source in one workspace view. Filter by status group (open and pending, resolved and compliant, closed and N.A.), severity band (critical, high, medium, low, info), category, and title substring on the dashboard findings view, then export the cohort as CSV or PDF for the triage stand-up, the leadership briefing, the audit fieldwork response, the remediation portfolio rebalance, or the inbound regulator query. The cohort reads against the live findings record across all parent engagements rather than against per-engagement spreadsheets stitched together by hand.

Get Started Free

No credit card required. Free plan available forever.

One workspace view for every cross-engagement cohort the programme runs

Vulnerability programmes that grow past one or two engagements quickly hit the question that per-engagement views cannot answer: which open critical findings are in flight across every active client this quarter, where does this specific weakness class show up across the workspace, which findings in the workspace map to a specific control family for the upcoming audit, how big is the partially implemented cohort feeding into the SOC 2 readiness review, which findings are still in progress past their target close date across every engagement, what is the workspace footprint of the customer release the security review is signing off. Each question reads across engagements, not within one.

SecPortal answers the cross-engagement question on the workspace dashboard findings view. The view reads every finding the workspace carries, scoped by workspace_id and ordered by updated_at descending. Status group, severity, category, and title filters compose to scope a precise cohort; the pagination and the total count tell the operator how large the cohort is before reading deeper; the CSV and PDF export buttons assemble up to two thousand rows for the audit reply, the board pack, or the regulator query. The same surface drives the Cmd+K palette, described separately as the fast-jump navigation lookup the palette is built for; the cohort discipline described here runs on the multi-filter dashboard view.

The cross-engagement questions the cohort discipline answers

The seven questions below are the recurring cross-engagement queries every internal vulnerability programme runs at least monthly. Each one frames a cohort that the per-engagement view cannot answer in one screen.

Which open critical findings are in flight across every active client this quarter?

The portfolio question. The cohort feeds the quarterly leadership briefing, the steering committee deck, and the workspace-level risk register snapshot. Per-engagement views answer this only by hand-aggregation; the cross-engagement filter answers it directly with one status group and severity selection.

Where does this specific vulnerability class show up across the workspace?

The CWE-cohort question. A new disclosed weakness, a customer-reported issue class, a fresh regulator advisory, or a sister-team incident drives the question. The cohort feeds the targeted remediation campaign and the security advisory response that names the affected projects rather than blanketing every engagement.

Which findings in the workspace map to a specific control family for the upcoming audit?

The audit-fieldwork question. The cohort feeds the evidence request response when the auditor asks for every open and accepted finding aligned to a control family across the in-scope systems. Per-engagement evidence collection takes days; the cross-engagement filter delivers the cohort the same morning the request lands.

How big is the partially implemented and not assessed cohort feeding into the SOC 2 readiness review?

The compliance-state question. Findings carrying the partially_implemented or not_assessed status read against the SOC 2 criteria the readiness review names. The cohort feeds the gap-list the readiness review owes the auditor and the remediation plan the response cycle commits to.

Which high and critical findings are still in_progress past their target close date across every engagement?

The SLA-cohort question. The cohort feeds the leadership escalation conversation, the named-owner review meeting, and the breach-rate calculation the leadership scorecard reads. The cross-engagement filter shows the in-progress overdue cohort across every project that the per-engagement view shows one project at a time.

What is the workspace footprint of the customer release the security review is signing off?

The release-readiness question. A customer release name or codename in finding titles or parent engagement titles surfaces every finding that touches the release across pre-release pentests, code scans, authenticated scans, and external scans. The cohort feeds the release security sign-off the release manager and the product security lead jointly own.

Which scanner-sourced findings still carry false_positive override across the workspace?

The override-audit question. The closed-N.A. group surfaces the false_positive cohort across every engagement. The cohort feeds the periodic suppression review the override programme runs to verify that suppressed findings are still legitimately suppressed and that no scanner update has overturned the original dismissal.

The filter stack that composes the cohort

Four filter layers compose to scope the cohort: status group, severity multi-filter, category and status multi-filter, title and engagement-title search. The layers compose in this order because the status group is the first frame every cohort needs, the severity layer is the second frame the leadership view reads against, the category layer carries the workspace s programme-shape tagging, and the search layer is the precise substring slice the cohort question targets.

Status group filter (one of four)

The status group filter chooses one of four buckets: All (every finding), Open and Pending (open, in_progress, reopened, non_compliant, not_implemented, ineffective, not_assessed, not_tested, partially_implemented, detected, triaged, contained, eradicated), Resolved and Compliant (resolved, verified, compliant, implemented, effective, recovered, closed), or Closed and N.A. (not_applicable, false_positive). The status group is the first filter because mixing open work with closed work hides the cohort the cross-engagement question is meant to answer.

Severity multi-filter (critical, high, medium, low, info)

Selecting one or more severity bands restricts the cohort to the matching CVSS-aligned severity values on the finding record. Critical plus High is the urgent-cohort filter that feeds the leadership escalation and the breach-rate calculation. Medium plus Low is the working-cohort filter that feeds the quarterly remediation plan. Info-only is the housekeeping-cohort filter that feeds the tooling-noise review and the false-positive register clean-up.

Category and status multi-filter

The category filter accepts any non-severity tag from the workspace s status, category, or programme-label set. The filter applies as an OR across status, OR across category, AND across the severity selection above. A workspace that tags findings by control family, asset class, programme cycle, or scanner source can read every cohort the tags express directly on the dashboard rather than re-aggregating outside the workspace.

Title and engagement-title search (ILIKE substring)

The search input runs a case-insensitive substring match across both the finding title and the parent engagement title in one query. The match composes with the status group and the multi-filter above, narrowing the cohort to a precise substring slice. The search is substring-pattern matching, not vector search or semantic search; the query string returns the literal substring matches across the workspace.

Naming recurring cohorts so the next cycle reads on the same boundary

The dashboard does not persist filter combinations as saved searches. The operating discipline preserves the cohort definition by naming the recurring cohort and re-applying the same filter combination on every cycle. The six naming examples below are common cross-engagement cohorts every internal vulnerability programme runs; pick the ones that map to the programme s recurring questions and document the filter signatures in the workspace runbook.

this-quarter-open-critical

Status group Open and Pending, severity multi-filter Critical, no search. Re-applied weekly. Cohort size feeds the steering-committee scorecard; cohort delta feeds the leadership escalation discussion.

this-cycle-overdue-high

Status group Open and Pending, status filter in_progress, severity multi-filter High plus Critical, sort by last-updated to surface stalled work. Re-applied at the weekly triage stand-up; the cohort feeds the named-owner check-in and the breach-rate calculation.

this-release-finding-footprint

Status group All, search input set to the release name or codename. Re-applied at the release readiness review; the cohort feeds the release security sign-off and the customer-facing security statement.

this-control-family-evidence-cohort

Status group Open and Pending plus Resolved and Compliant, category multi-filter set to the workspace s control-family tag, sort by last-updated. Re-applied per audit cycle; the cohort feeds the audit fieldwork evidence request response and the compliance-tracking citation chain.

this-suppression-audit-cohort

Status group Closed and N.A., status filter false_positive, no severity restriction. Re-applied quarterly; the cohort feeds the override-programme suppression review and the finding-overrides audit chain.

this-vulnerability-class-campaign

Status group Open and Pending, search input set to the CWE shorthand or vulnerability-class name (sql injection, missing security headers, weak tls, hardcoded credential). Re-applied per remediation campaign; the cohort feeds the targeted closure plan and the after-action narrative.

Where the cohort lands when it leaves the dashboard

The cohort assembly hands off to four destinations: the CSV export for spreadsheet pivots and downstream documents, the PDF export for audit and board attachments, the per-row deep-link to the parent engagement for per-finding workflows, and the activity log entry that captures the export event with the named operator.

CSV export through the dashboard

The CSV button on the dashboard findings view assembles the cohort with the current status group, severity multi-filter, category multi-filter, and search applied, then issues an export=true API call returning up to two thousand rows. The browser writes Items Export.csv with the headline columns: finding title, severity, status, category, parent engagement title, parent client company name, engagement type, last-updated timestamp, and creation timestamp. The CSV reads cleanly into a spreadsheet for portfolio pivots or into a downstream document for the audit response.

PDF export through the dashboard

The PDF button on the dashboard renders the same cohort as Items Export.pdf through html2pdf. The PDF reads as a structured page-layout document the response team attaches to the audit fieldwork reply, the regulator query response, the board pack appendix, or the customer evidence room handover. The PDF carries the cohort as the data the leadership read; the slide deck cites the PDF as the evidence behind the headline number.

Deep-link from any cohort row to the parent engagement

Every row in the cohort table deep-links to the parent engagement scoped to the finding. The cohort assembly hands off to per-finding triage, remediation tracking, retesting, finding overrides, evidence package preparation, or fix verification without losing the context the cohort surfaced. The deep-link keeps the cross-engagement cohort connected to the per-finding workflows the platform runs.

Activity-log capture of the export event

The export event writes a timestamped entry on the workspace activity log under the named operator. The audit reads the cross-engagement export as a deliberate operational action rather than as a screenshot pulled from a laptop. A later question about what was exported, by whom, and when reads from the activity log; the activity log CSV export, in turn, becomes part of the audit-evidence chain.

Failure modes the cohort discipline replaces

Programmes that lack a cross-engagement cohort discipline fall into seven recurring failure modes. Each one inflates time-to-answer on cross-cutting questions and weakens the audit chain on cohort-shaped evidence. Naming the failure modes is the first step in replacing the ad-hoc spreadsheet stitching with a workspace-level cohort surface.

Spreadsheet stitching from per-engagement exports

The cohort is reconstructed every cycle by exporting each engagement to CSV, opening the files in a spreadsheet, and pivoting by severity and status. The reconstruction takes days, the freshness lag is one cycle behind the live record, and the engagement count drifts away from the workspace as new engagements land between exports. The cross-engagement filter on the live record is the operating fix; the workspace view is the source of truth, not the spreadsheet copy.

Cohort question framed against the wrong status group

A leadership question about open work pulls a cohort across All Statuses instead of Open and Pending. The cohort returns thirteen open statuses plus seven resolved statuses plus two closed-N.A. statuses pooled together, and the headline number on the report no longer represents the open work the question asked about. The status group filter is the first frame the cohort applies, not an optional refinement.

CWE-cohort assembled by reading engagement titles instead of finding titles

A targeted remediation campaign on a specific weakness class reads parent engagement titles for the class name. The cohort misses every finding logged with the class in the finding title but inside a generically-named parent engagement (such as Q3 External Scan or Customer Pre-Release Review). The search runs across both the finding title and the engagement title in one query; the cohort assembly that targets a vulnerability class queries the finding title across the workspace, not the engagement title in isolation.

Audit fieldwork response built by walking the engagement list

The auditor asks for every finding aligned to a control family across the in-scope systems. The response team opens each in-scope engagement, reads the findings list, and copies matches into a separate document. The walk takes a day per engagement, the response misses findings tagged on the control family but stored in engagements the team did not recall in scope, and the chain of custody is screenshots on a laptop. The cross-engagement category filter delivers the cohort directly with the engagement and client metadata intact on every row.

No deliberate cohort discipline; every cross-cutting question is ad-hoc

A workspace that runs cohort assembly through one-off queries each time loses the discipline that makes the next cohort fast. Naming the recurring cohorts (this-quarter-open-critical, this-cycle-overdue-high, this-release-finding-footprint, this-control-family-evidence-cohort, this-suppression-audit-cohort) and re-applying the same filter combination each time keeps the cohorts comparable across cycles. The dashboard does not save the cohort definition; the operating discipline saves the cohort definition by naming it and re-applying the same filter combination.

Cohort export pulled without the filter signature on the activity log

A bulk export of findings reaches a stakeholder without the filter signature that produced it. The recipient cannot reconstruct what the export represents, the audit cannot verify what the operator intended, and a second pull two weeks later produces a different cohort with the same name. Exporting through the workspace records the export event on the activity log; the filter combination that produced it is documented in the cohort-naming convention the workspace runs.

Cohort larger than two thousand rows treated as the cap rather than as the warning

A cohort returns the full two-thousand-row export ceiling and the operator takes the export at face value. The ceiling is the upper bound the API enforces per request, not the size of the cohort; if the cohort is larger, the filter is too broad and the export is truncated. Narrow the filter, export the slices, and concatenate the slices outside the workspace, or rebalance the cohort question to a tighter slice that fits inside one export.

How the workspace surfaces the cohort discipline

Nine platform surfaces participate in the cross-engagement cohort discipline. The dashboard findings view is the operating surface; the Cmd+K palette is the complementary navigation lookup; the API, the bulk import path, the finding overrides feature, the activity log, the AI reports surface, and the compliance tracking feature all read against or feed into the same record the cohort assembly returns.

Workspace findings dashboard

The /dashboard/findings page reads every finding the workspace carries, scoped by workspace_id, ordered by updated_at descending, with the parent engagement and parent client joined on every row. Pagination defaults to fifty rows per page; the page header carries the total count so the operator knows whether the cohort is ten rows, five hundred rows, or two thousand rows before reading deeper.

Findings API surface

The /api/findings GET endpoint returns the same data the dashboard reads. The API accepts page, pageSize (max 100), statusGroup, categories (comma-separated), search, and export (true returns up to two thousand rows in one response). Every response carries a private cache header with a thirty-second max age so a tab issuing successive filter adjustments stays responsive without hitting the database on every keystroke. The endpoint runs on the same workspace_id and team-role boundary as the rest of the platform.

Cmd+K palette versus the dashboard cohort surface

The Cmd+K palette returns up to five clients plus five engagements plus five findings on a substring match scoped to the workspace, then deep-links to the source record. The palette is the navigation lookup, not the cohort surface; it is built for fast jumps to a single record by name. The cross-engagement cohort discipline runs on the dashboard findings view, which carries the multi-filter logic, the pagination, the joined client and engagement metadata, and the CSV and PDF export the cohort assembly needs.

Joined engagement and client metadata on every row

Every cohort row carries the parent engagement title, the engagement type, the engagement status, and the parent client company name. The cohort reads as a portfolio view rather than as a flat finding list; the leadership briefing, the audit fieldwork response, and the targeted remediation campaign all read against the engagement and client context the joined select preserves on every row.

Bulk finding import as the upstream cohort enabler

A workspace running cross-engagement cohort assembly across third-party scanner output relies on bulk finding import to land Nessus, Burp Suite, and CSV exports on the right engagements with consistent severity, category, and title fields. The cohort assembly downstream reads against the imported records on the same boundary as native findings; the import column mapping is where the cross-engagement cohort discipline gets its consistency.

Finding overrides as cohort filters

The Closed and N.A. status group surfaces the false_positive cohort that the finding overrides feature carries on the workspace. The cohort assembly reads the suppressed-set as a deliberately scoped slice for the periodic suppression review rather than as a hidden tail of the open-cohort. The recurring false-positive review reads against the same dashboard view the operating cohort discipline already runs.

Activity log on every cohort export

The workspace activity log writes a timestamped entry on every export event under the named operator. The audit reads cohort assembly as a named operational action, not as an off-platform spreadsheet manipulation. The activity log itself is exportable as CSV per the activity log feature, so the cohort exports and the chain of custody behind them are themselves a cohort the audit can read.

AI reports drafted against the same cohort signal

The AI reports feature drafts narrative report text on engagement records. A cohort assembled across engagements feeds the next leadership cycle by re-reading the cohort filter on the next cadence and asking the AI reports surface to draft the engagement-by-engagement summary the cohort headline cites. The cohort discipline is the input; the AI report drafting is the narrative layer that reads against the same operating record the cohort filter returned.

Compliance tracking citation chain

A cohort filtered to a control family becomes the citation set the compliance tracking feature reads against the audit framework mapping. The cohort headline (open count, overdue count, accepted count, partially implemented count) reads back to the auditor as the evidence pack referenced in the cited control. The cohort assembly is the data; the compliance tracking feature is the mapping the audit reads against.

Operating checklist for cross-engagement cohort assembly

The twelve-step checklist below is the operating discipline the workspace runs on every cross-engagement cohort. Following the order keeps the cohort focused, the export auditable, and the recurring cohort comparable across cycles.

Frame the cohort question before opening the dashboard so the filter combination targets one named cohort rather than a generic dump.
Apply the status group filter first; the four-bucket model (All, Open and Pending, Resolved and Compliant, Closed and N.A.) is the first frame every cohort needs.
Stack the severity multi-filter next; Critical plus High is the urgent cohort, Medium plus Low is the working cohort, Info-only is the housekeeping cohort.
Add the category multi-filter to scope by control family, asset class, programme cycle, or scanner source where the workspace s tagging conventions support it.
Add the title or engagement-title search last; the substring composes with the filter stack to narrow the cohort to a precise slice.
Read the row count on the page header to size the cohort (ten rows, five hundred rows, two thousand rows) before exporting.
Export to CSV for spreadsheet pivots; export to PDF for audit fieldwork response or board pack appendix.
Name the cohort once it is recurring (this-quarter-open-critical, this-cycle-overdue-high, this-release-finding-footprint, this-control-family-evidence-cohort) and re-apply the same filter combination on the next cycle.
Cite the cohort filter signature when the export leaves the workspace; the recipient should be able to reconstruct what the cohort represents.
Use the deep-link on each row to hand the cohort off to per-finding triage, remediation tracking, retesting, finding overrides, or evidence package preparation.
Run the activity log export periodically to keep the chain of custody on cohort exports alongside the cohort itself.
Narrow the filter and export in slices when the cohort exceeds the two-thousand-row per-request ceiling.

How the cohort reads against audit framework expectations

Six framework crosswalks below explain how the cross-engagement cohort discipline reads as operating evidence against ISO 27001, SOC 2, PCI DSS, NIST SP 800-53, NIST CSF 2.0, and CIS Controls. The cohort headline (open count, overdue count, accepted count, partially implemented count) plus the cited cohort export plus the activity log entry on the export event are the evidence package the auditor reads against each citation. The mapping below is the audit reader s view; the compliance tracking feature carries the workspace mapping the audit reads against.

Framework citation	How the cohort reads against the citation
ISO 27001 Annex A 8.8 and A 5.36	Management of technical vulnerabilities and compliance with policies for information security expect a workspace-level view of open vulnerabilities, accepted exceptions, and closed-with-evidence work. The cross-engagement cohort filtered to Open and Pending across the workspace is the operating evidence the auditor reads against A 8.8; the cohort filtered to a control family with status and category tags is the operating evidence against A 5.36.
SOC 2 CC4.1 and CC7.1	Monitoring of controls and detection of security events expect the entity to maintain an inventory of identified vulnerabilities and the response status of each. The cross-engagement cohort filtered by status group and severity reads as the auditor s view of CC4.1 and CC7.1 evidence across the workspace, with the parent engagement and parent client metadata on every row providing the system-and-organisation context.
PCI DSS 6.3.1 and 11.3	Identifying and addressing security vulnerabilities and performing external and internal vulnerability scans expect the entity to track every identified vulnerability through to remediation. The cross-engagement cohort filtered to the in-scope assets and the Open and Pending status group reads as the operating evidence the QSA examines against 6.3.1 and 11.3.
NIST SP 800-53 RA-5 and CA-7	Vulnerability scanning and continuous monitoring expect the organisation to maintain workspace-level visibility of identified vulnerabilities and the operational status of each. The cross-engagement cohort across all in-scope engagements is the operating evidence the assessment reads against RA-5 (a) (the vulnerability scan inventory) and CA-7 (the continuous monitoring strategy execution).
NIST CSF 2.0 ID.RA and DE.CM	Risk assessment and security continuous monitoring expect the organisation to maintain a workspace-level view of identified risks and the detection-monitoring posture across the cyber-asset inventory. The cross-engagement cohort filtered to severity and status reads as the ID.RA-01 (asset vulnerabilities identified) and DE.CM-09 (technology assets monitored) evidence on the operating record.
CIS Controls v8.1 Control 7 and Control 17	Continuous vulnerability management and incident response management expect the organisation to maintain a vulnerability inventory and a response-cohort view across the in-scope systems. The cross-engagement cohort filtered to Open and Pending status group and tagged by control family reads as the operating evidence the assessor checks against safeguard 7.1 (process to remediate detected vulnerabilities) and safeguard 17.4 (incident response process documentation cohort).

Scope and limitations the cohort discipline honours

The six limits below describe what the cross-engagement cohort surface does and does not do today. Programmes that need to operate outside these limits maintain the cohort discipline through the operator at the dashboard, the workspace runbook conventions, or downstream tooling outside the platform.

No saved-search profiles inside the dashboard

The dashboard does not persist filter combinations as named searches the user can revisit with one click. The cohort definition is preserved by the operating discipline that names the cohort and re-applies the same filter combination, not by a UI feature. Programmes that need many recurring cohorts maintain the cohort definitions in a runbook or in the workspace conventions documentation outside the dashboard.

No structured query language or analytical aggregation surface

The dashboard returns the cohort as a row-level table with the joined engagement and client context. It does not expose a SQL-like query interface, a pivot-table builder, or a built-in group-by aggregation across severity, status, engagement, or client. Programmes that need aggregated cohort counts assemble those counts outside the dashboard by exporting the cohort to CSV and running the aggregation in a spreadsheet or in a downstream analytics tool.

No external query API beyond the platform endpoints

The /api/findings endpoint is built for the dashboard surface, not for third-party automation. The endpoint returns paginated rows for the dashboard and bulk exports for the in-tab export buttons; it does not ship with webhooks, push integrations to Slack or Jira or SIEM, or external query syntax for programmatic cohort assembly outside the workspace UI. Cohort assembly runs through the operator at the dashboard.

No semantic similarity search; substring matching only

The search input matches the literal substring on the finding title and the parent engagement title. A query for broken access returns titles that contain the substring; it does not surface a finding titled improper authorisation on POST /admin unless the title actually contains the word fragment. Cohort discipline relies on consistent finding-title conventions (300+ finding templates carry stable titles, the bulk import column mapping carries the source title verbatim, manual entry follows the workspace s naming conventions) rather than on semantic inference.

No cross-workspace federation

Every cohort assembly is scoped to one workspace. A security consultancy or enterprise running multiple workspaces switches workspace and re-applies the cohort filter rather than seeing pooled cross-workspace results. The single-tenant scope is the platform model and keeps the access boundary simple; cross-workspace cohort assembly happens off-platform if it happens at all.

Export ceiling of two thousand rows per request

The export=true API call caps at two thousand rows per request. Cohorts larger than two thousand rows narrow the filter (a tighter severity band, a tighter date range through the sort-by-updated, a tighter category) and export in slices that are then concatenated outside the workspace. The cap is the per-request upper bound the API enforces, not the size of the cohort the workspace can carry; a workspace with tens of thousands of findings still reads every row through the paginated dashboard view.

Buyer and operator pairings

Six audience pairings below show how the cross-engagement cohort discipline lands for each operating buyer. Each pairing reads the cohort surface against the question the audience asks every operating cycle.

Internal security teams

Centralise vulnerability work across every active engagement, every active client, and every scanner source on one workspace view. The cohort discipline replaces per-engagement spreadsheet stitching with a live cross-engagement view that the next triage stand-up, the next leadership briefing, and the next audit cycle all read against.

Vulnerability management teams

Assemble the open-cohort, the overdue-cohort, the partial-fix cohort, and the suppression-audit cohort directly from the workspace findings view. The cohort definitions name the recurring cross-engagement questions the programme runs, and the dashboard returns them on the same boundary every cycle.

AppSec teams

Read every finding for a customer release across pre-release pentests, code scans, authenticated scans, and external scans by searching the release codename across the workspace. The release security sign-off reads against the workspace cohort rather than against per-engagement screenshots stitched into a slide.

GRC and compliance teams

Respond to audit fieldwork evidence requests and regulator queries with a cross-engagement cohort that filters by control family, status group, and severity in seconds rather than walking the engagement list by hand. The CSV and PDF exports attach to the audit response with the engagement and client metadata intact on every row.

CISOs and security operations leaders

Read the open-critical cohort, the overdue cohort, the exception cohort, and the partially implemented cohort across every engagement in one place. The leadership briefing reads against the same operating record the workspace runs; the headline number on the board pack reconciles to the cohort export it cites.

Security engineering teams

Drive targeted remediation campaigns on specific weakness classes by reading the cross-engagement cohort for the class across the workspace. The campaign plan, the named-owner check-in, and the after-action narrative all read against the same cohort the workspace returns on the dashboard.

Where the cohort hands off to the next discipline

Cross-engagement cohort assembly feeds the operating disciplines that read against the cohort the dashboard returns. The cohort itself is the data; the next disciplines are where the data lands.

The aged-cohort and the overdue-cohort feed vulnerability backlog management, where the four aging buckets (Fresh, Working, Aging, Risk debt) read against the status group plus age-by-updated cohort the dashboard returns.

The named-cohort headline counts feed security leadership reporting, where the board view, the audit-committee briefing, and the operator queue all read from the cohort the workspace returns rather than from a parallel slide deck authored independently.

The control-family cohort feeds audit fieldwork evidence request fulfilment, where the auditor s request for every open and accepted finding aligned to a control family reads as the cross-engagement cohort the operator returns on the same dashboard view.

The severity-and-category cohort feeds vulnerability prioritisation, where the prioritisation decision per finding reads against the cohort the workspace returns rather than against a per-engagement triage in isolation.

The overdue-cohort feeds vulnerability SLA management, where the SLA-breach calculation reads against the cohort filtered by status group plus severity plus the target-close-date logic the SLA discipline runs.

The aged-cohort by age band feeds security debt portfolio management, where the debt portfolio is the cross-engagement view of the aged-and-still-open cohort the workspace carries across cycles.

The release-footprint cohort feeds security finding fix verification, where the closure gate per finding reads against the cohort filtered by the release codename across all parent engagements that touched the release.

The substring-match candidate-pair cohort feeds vulnerability finding merge and supersede workflow, where two finding records that describe one underlying issue are consolidated into one identity-coherent record through the finding state model, the override primitive, and the activity log. The cross-engagement substring search surfaces the duplicate candidates; the merge discipline closes them into one surviving identity per underlying vulnerability across the workspace.

Frequently asked questions about cross-engagement finding search

What is cross-engagement finding search?

Cross-engagement finding search is the operating discipline of assembling vulnerability cohorts across every engagement, every client, and every scanner source in one workspace view. It runs on the dashboard findings view with status group, severity, category, and title filters, then exports the cohort as CSV or PDF for the next operating discipline (triage stand-up, leadership briefing, audit fieldwork response, remediation portfolio rebalance, regulator reply). The cohort reads against the live engagement record across all parent engagements rather than against per-engagement exports stitched together by hand.

How does the cross-engagement cohort differ from the Cmd+K global search?

The Cmd+K palette is a navigation lookup: type two characters and it returns up to five clients plus five engagements plus five findings on a substring match, then deep-links to the source record. The dashboard findings view is the cohort surface: it returns every matching finding across the workspace with the parent engagement and parent client metadata on every row, paginates fifty rows at a time, supports status group plus severity plus category plus search composition, and exports up to two thousand rows as CSV or PDF. The palette is for fast jumps; the dashboard is for cohort assembly.

What status groups does the cross-engagement filter support?

Four buckets: All (every finding regardless of status), Open and Pending (the thirteen unfinished-work statuses including open, in_progress, reopened, non_compliant, not_implemented, ineffective, not_assessed, not_tested, partially_implemented, detected, triaged, contained, eradicated), Resolved and Compliant (the seven closed-success statuses including resolved, verified, compliant, implemented, effective, recovered, closed), and Closed and N.A. (the two final-non-action statuses not_applicable and false_positive). The status group is the first filter every cohort applies because mixing open work with closed work hides the cohort the cross-engagement question is meant to surface.

How does the severity multi-filter interact with the category multi-filter?

The dashboard category multi-filter accepts both severity values (critical, high, medium, low, info) and any non-severity tag (status names, category names, programme-label tags the workspace applies). Selections within the severity set OR together (Critical OR High); selections within the non-severity set OR together (Open status OR In progress status); the two classes AND across each other. The composition lets a cohort target Critical plus High open work across one control family in one filter combination.

How big can a cross-engagement cohort be?

The dashboard paginates fifty rows at a time and shows the total count on the page header. The CSV and PDF export buttons assemble up to two thousand rows per request through the export=true API parameter. Cohorts larger than two thousand rows narrow the filter (tighter severity band, tighter category, tighter date range through the sort-by-updated) and export in slices that are then concatenated outside the workspace. The cap is the per-request upper bound the API enforces, not the size of the cohort the workspace can carry.

Does the dashboard support saved cohorts or named searches?

The dashboard does not persist filter combinations as named searches the user can revisit with one click. The operating discipline preserves the cohort definition: name the recurring cohort (this-quarter-open-critical, this-cycle-overdue-high, this-release-finding-footprint, this-control-family-evidence-cohort, this-suppression-audit-cohort) and re-apply the same filter combination on the next cycle. Programmes with many recurring cohorts maintain the cohort definitions in a runbook or in the workspace conventions documentation outside the dashboard.

How is the cross-engagement search scoped across tenants?

Every dashboard query and every /api/findings request filters by workspace_id derived from the authenticated profile before the dashboard query runs. One operator never sees another tenant s cohort. The role check on the team_role boundary runs before the query plan executes, so a non-consultant role cannot reach a cross-engagement view scoped to clients the role does not have access to. Cross-workspace federation is not supported; a security consultancy or enterprise running multiple workspaces switches workspace and re-applies the cohort filter.

What does the CSV export include?

The CSV export writes Items Export.csv with the headline columns: finding title, severity, status, category, parent engagement title, parent client company name, engagement type, last-updated timestamp, and creation timestamp. The CSV reads cleanly into a spreadsheet for portfolio pivots, into a downstream document for the audit response, or into an analytics tool for cross-cycle trend assembly. The export carries the cohort the dashboard view was returning at the moment of the export click.

What does the PDF export include?

The PDF export writes Items Export.pdf through html2pdf, rendering the cohort table as a structured page-layout document. The PDF attaches to the audit fieldwork reply, the regulator query response, the board pack appendix, or the customer evidence room handover. The PDF carries the cohort as the data the leadership read; the slide deck cites the PDF as the evidence behind the headline number rather than as a screenshot of the dashboard view.

How does the cross-engagement search compose with finding overrides?

Findings with a false_positive override show up in the Closed and N.A. status group; findings with an accepted_risk override show up in their original severity band on the cohort with the status the workspace has assigned. The cross-engagement cohort filtered to Closed and N.A. surfaces the false-positive cohort across the workspace for the periodic suppression review; the cohort filtered to Open and Pending surfaces the actively-tracked work including findings carrying severity overrides. The override decision lives on the finding overrides surface; the cohort surface reads the override state on the row.

Does the dashboard support cross-engagement aggregation or pivots?

The dashboard returns the cohort as a row-level table with the joined engagement and client context. It does not ship a built-in pivot table or group-by aggregation across severity, status, engagement, or client. Programmes that need aggregated cohort counts assemble those outside the dashboard by exporting the cohort to CSV and running the aggregation in a spreadsheet or in a downstream analytics tool. The cohort assembly returns the data; the aggregation runs outside the workspace.

How does cross-engagement cohort discipline feed leadership reporting?

Named cohorts (this-quarter-open-critical, this-cycle-overdue-high, this-release-finding-footprint, this-control-family-evidence-cohort) feed the recurring leadership cadence by re-applying the same filter combination on every cycle. The cohort size, the cohort delta cycle over cycle, the cohort age distribution, and the cohort owner mix become the leadership scorecard numbers. The headline number on the board pack reconciles to the cohort export it cites because both read from the live workspace findings record.

How it works in SecPortal

A streamlined workflow from start to finish.

Frame the cohort question against the workspace findings view

Every cross-engagement cohort starts with a question the per-engagement view cannot answer. Examples: which open critical findings are still in flight across every active client, how many of last month s scanner ingest landed as resolved versus closed across the portfolio, where does this specific CWE class show up across the workspace, what is the size of the partially implemented control cohort feeding into the SOC 2 audit response, which engagements still carry not assessed status this quarter. Frame the question first so the filter combination targets a single, named cohort the report can stand on rather than a generic dump.

Open the workspace dashboard findings view

The dashboard findings view at /dashboard/findings reads every finding the workspace carries across every client and engagement, scoped by workspace_id and ordered by updated_at descending. The page paginates fifty rows at a time, returns the parent engagement title and client company name on every row through a joined select, and renders the severity and status badges so the cohort is readable at a glance. Bookmark the URL; the cohort discipline returns to it daily.

Apply the status group filter that matches the cohort intent

The status group filter narrows the workspace to one of four states. All returns every finding. Open and Pending returns the thirteen statuses that represent unfinished work (open, in_progress, reopened, non_compliant, not_implemented, ineffective, not_assessed, not_tested, partially_implemented, detected, triaged, contained, eradicated). Resolved and Compliant returns the seven closed-success statuses (resolved, verified, compliant, implemented, effective, recovered, closed). Closed and N.A. returns the two final-non-action statuses (not_applicable, false_positive). Picking the right group is the first filter every cross-engagement cohort applies, because mixing open work with closed work hides the cohort the report is meant to surface.

Stack severity, status, and category filters to scope the cohort

The category multi-filter reads the five severity values (critical, high, medium, low, info) as severity matches and every other tag as status or category matches. Selecting Critical plus High narrows the cohort to the urgent slice. Selecting a specific status (in_progress) on top of an open status group narrows further to the active-remediation cohort. Selecting a category tag (a CWE family label, a control family label, a programme cycle label the workspace applies on intake) narrows to a programme-shaped cohort the leadership view can read. The OR-within-class plus AND-across-classes shape of the filter is the operating logic; layer the filters intentionally so the cohort is what the question asked.

Add the title or engagement title search for the precise cohort

The search input runs an ILIKE substring match across the finding title and the parent engagement title in one query. Typing a CWE shorthand returns every finding whose title contains the substring across every engagement (SQL injection across all clients, missing security headers across every external scan, weak TLS across every cloud assessment). Typing an engagement codename returns every finding inside that engagement set. Typing a customer release name returns every finding inside the engagements that mention the release. The search composes with the status and category filters, so the substring narrows the existing filter rather than replacing it.

Read the cohort in the dashboard table with engagement and client context on every row

Every row in the cohort table carries the finding title, severity badge, status badge, parent engagement title, parent client company name, engagement type, last-updated timestamp, and a deep-link to the parent engagement scoped to the finding. The fifty-row pagination keeps the visible cohort scannable; the total count at the page header tells the operator whether the cohort is ten rows, five hundred rows, or two thousand rows so the next action (read in place, export to CSV, export to PDF) lands on the right scale. The cross-tenant boundary is enforced at the workspace_id filter; one operator never sees another tenant s cohort.

Export the cohort as CSV or PDF when the report needs to leave the dashboard

The CSV export button assembles the current cohort with the current filters and the current search applied, retrieves up to two thousand rows in one request through the export=true API parameter, and writes Items Export.csv to the browser with the headline columns (title, severity, status, category, parent engagement, parent client, dates). The PDF export button renders the same cohort as Items Export.pdf through html2pdf for the audit fieldwork response, the regulator reply, the board pack appendix, or the customer evidence room handover. The two-thousand-row cap is the export ceiling per request; larger cohorts narrow the filter and export in slices, then concatenate outside the workspace.

Hand the cohort to the next operating discipline through deep links

Each row deep-links to the parent engagement scoped to the finding, so the cohort assembly hands off to per-finding triage, remediation tracking, retesting, finding overrides, or evidence package preparation without losing the context the cohort surfaced. The activity log writes the export event and the filter signature on the workspace so the audit reads the cohort assembly as a named operational action rather than as a screenshot pulled from a laptop. The cohort that fed the leadership briefing reads back two months later by re-applying the same filter combination on the same dashboard view.

Features that power this workflow

Global search across every engagement, finding, and client

Vulnerability management software that tracks every finding

Bulk finding import bring your scanner data with you

Finding overrides that survive every scan cycle

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

AI-powered reports in seconds, not days

Compliance tracking without a full GRC platform

Orchestrate every security engagement from start to finish

Monitor continuously catch regressions early

Document management for every security engagement

Read every finding across every engagement on one cohort view

Status-group, severity, category, and title filters on the workspace findings view with CSV and PDF export. The cohort that feeds your triage stand-up, leadership briefing, audit fieldwork response, and regulator reply reads against the live record across every engagement and client. Start free.