For SOC analysts and security operations analysts
who triage scanner output and pentest findings into a defensible queue

A finding queue, a CVSS calibration surface, and an audit trail an analyst can actually run

SOC analysts and security operations analysts triage what landed overnight, validate scanner output against reality, calibrate severity for the environment, deduplicate against the existing backlog, route findings to the named engineering owner, and verify that the fix held on retest. The work spans scanner output from external scans, authenticated scans, code scans, third-party pentest reports, and manual review items, and the analyst typically runs it across a vulnerability scanner console, a SAST or SCA dashboard, a pentest report PDF, a spreadsheet for the queue, and a ticketing tool for the engineering hand-off. The queue does not sit on one record, the calibration story is in a comment thread, and the audit trail rebuilds from chat history every time the auditor asks.

SecPortal gives in-house SOC and security operations analysts one workspace for findings consolidation, CVSS 3.1 calibration on the engagement record, the open or in_progress or resolved or verified or reopened status workflow, scanner imports for Nessus and Burp Suite and custom CSV, scheduled scans with diff-aware regression detection, evidence attachments on the finding, retest validation, exception capture with the structured decision chain, and the append-only activity log that ties the lifecycle together. Analysts work one queue rather than five, the calibration is a record event rather than a message in a thread, and the audit trail is one record rather than a multi-team excavation. The analyst gets back the hours that used to disappear into reconciliation between tools.

Capabilities SOC analysts use day to day

How analysts run triage inside SecPortal

A triage discipline that holds up between cycles operates on a small set of habits. SecPortal makes each one a record event rather than a tribal-knowledge convention.

From new finding to verified close, on one engagement record

The analyst loop for security operations is land, validate, calibrate, deduplicate, assign, and verify. SecPortal runs that loop on one engagement record so the analyst, the engineering owner, the security operations leader, and the audit reviewer all read from the same source rather than from four reconciled documents.

1. 1A new finding lands on the engagement queue, either from a scheduled external, authenticated, or code scan run, from a bulk import of Nessus, Burp Suite, or custom CSV output, or from a manual entry against an internal review. The analyst sees CVSS 3.1 vector, severity, scanner source, asset context, and the timestamp on the record without flipping consoles.
2. 2The analyst validates the detection. Reproduce the request and response, confirm the response shape against the scanner claim, and record the validation evidence on the finding. False positives stay on the record with the reproduction attempt and the reason rather than disappearing, so the next scan run does not re-flag the same finding without context.
3. 3Calibrate severity for the environment using the CVSS 3.1 environmental and temporal vectors on the engagement record. The original scanner-supplied score is preserved alongside the calibrated score, so the analyst can defend the recalibration in front of the security committee, the engineering owner, or the audit reviewer without reconstructing the rationale from chat history.
4. 4Deduplicate against the existing backlog using hostname, URL, parameter, method, CWE, and CVE as primary signals. When two scanners surface the same underlying issue, merge into the canonical entry with both source links preserved. The deduplicated count is the count the analyst defends in front of the engineering owner and the leadership view.
5. 5Assign the finding to the named engineering owner, set the severity-driven SLA window, attach the OWASP and framework mapping where it applies, and move the state from open to in_progress when investigation begins. The activity log records the assignment with actor and timestamp, so the hand-off to the engineering side is one record rather than an email thread.
6. 6On retest, run the targeted scan against the original asset, validate the fix, and move the finding state from resolved to verified. If the regression appears on the next scheduled run, the diff endpoint surfaces the reopen, and the analyst moves the state to reopened on the same record with the regression rationale. The close decision survives scanner version changes, tester rotation, and tool migrations because the trail is one record across the lifecycle.

Where the analyst view connects to the rest of the workspace

Most analyst teams adopt SecPortal in three phases: bring scanner output and pentest findings onto one engagement record so the queue is one queue, layer in the CVSS calibration discipline and the deduplication signals so the count the analyst defends is the count the leadership view reads, then operationalise the retest verification and the exception governance so the close decision survives the audit cycle. The relevant feature, workflow, and research pages explain each phase in detail.

• The findings repository, the CVSS calibration surface, and the open or in_progress or resolved or verified or reopened state workflow live on the findings management feature page, the append-only audit record on the activity log feature page, and the engagement-scoped access controls on the team management feature page.
• The scheduled external, authenticated, and code scans the analyst queue pulls from sit on the continuous monitoring feature page, the authenticated DAST detail on the authenticated scanning feature page, and the code scan detail on the code scanning feature page.
• The triage workflow itself sits on the scanner result triage use case, the bulk import handling on the bulk finding import use case, and the retest validation discipline on the retesting use case.
• The exception register with the structured decision chain sits on the vulnerability acceptance and exception management use case, the SLA window enforcement on the vulnerability SLA management use case, and the engineering hand-off discipline on the scanner to ticket hand-off governance use case.
• The output deduplication signals the analyst leans on are covered on the scanner output deduplication guide, the scheduling and baseline cadence on the scan scheduling and baseline cadence guide, and the false positive triage workflow on the scanner false positives guide.
• The deeper analysis of why the analyst queue grows faster than capacity sits on the ingest vs remediation capacity research, the per-finding lifecycle frame on the mean time to detect vs remediate research, and the durability picture on the vulnerability reopen rate research.

For analyst teams evaluating against bundled enterprise platforms

Analyst teams evaluating consolidation tend to compare SecPortal against bundled enterprise vulnerability platforms, against issue trackers used as a finding queue, against open source findings hubs, and against scanner-vendor consoles. The detailed side-by-side comparisons cover the operational footprint and the analyst-side cost on each model.

• The SecPortal vs DefectDojo comparison covers the analyst-side move from a self-hosted findings hub to a managed delivery platform with authenticated scanning, encrypted credential storage, AI reporting, and a branded portal view.
• The SecPortal vs Jira comparison covers the workspace model versus an issue tracker with a vulnerability template, where severity, evidence, retests, and OWASP mapping live on the engagement record rather than on a ticket comment trail the analyst has to maintain.
• The SecPortal vs Nessus comparison covers the analyst-side trade-off between a scanner console with a separate triage spreadsheet and a workspace where scanner output, calibration, deduplication, and retest verification share one record.
• The SecPortal vs Rapid7 comparison covers the trade-off between a bundled vulnerability platform and a workspace where the scanners themselves run alongside the triage queue and the engagement record.
• The SecPortal vs Tenable.io comparison covers the trade-off between a vulnerability management suite and a workspace where findings, scans, retests, and the leadership view all read from one engagement record.

SecPortal is built for SOC and security operations analysts that want one platform for the full land-validate-calibrate-deduplicate-assign-verify loop: live findings with the open or in_progress or resolved or verified or reopened state workflow, CVSS 3.1 calibration on the engagement record, scanner imports for Nessus and Burp Suite and custom CSV, scheduled scans with diff-aware regression detection, retest validation, exception capture with the structured decision chain, role-based access, multi-factor authentication, and an append-only activity log. Engineering owners get a clean hand-off, the security operations leader gets a defensible queue posture between assessments, and the analyst stops being the human reconciliation layer between the scanner and the spreadsheet.

If your function sits closer to running the recurring SecOps cadence at the leadership level rather than triaging the operator queue, the sister page SecPortal for security operations leaders covers findings consolidation, scheduled scanning, severity-driven SLA tracking, exception governance, retest evidence, AI-assisted reporting, and the activity log on a single workspace from the SecOps leadership side.

If your function sits closer to running the vulnerability backlog at the programme level rather than the per-finding triage queue, the SecPortal for vulnerability management teams page covers SLA enforcement, exception management, the prioritisation function, and the cross-source consolidation discipline a vulnerability management programme depends on.

If your function sits closer to incident response and detection-response work rather than per-finding scanner triage, the incident response use case covers detection-to-containment-to-eradication-to-recovery on the engagement record, and the PSIRT product security incident response use case covers the vendor-side product-vulnerability response workflow that runs from any inbound channel through coordinated disclosure.

If the analyst function reports up to a security leader who needs the leadership view on the same record the analysts run on, the SecPortal for CISOs and security leaders page covers the program-level reporting workflow that sits on top of the analyst queue without rebuilding a deck every quarter.