Every security workflow
in one platform
From a single penetration test to a continuous security testing programme, SecPortal adapts to how your team actually works.
No credit card required. Free plan available forever.
Penetration testing
From scoping through to client delivery, manage every penetration test in one place. Log findings with CVSS scores, generate AI reports, and deliver through your branded portal.
Learn moreCybersecurity risk assessment
Run cybersecurity risk assessments and vulnerability assessments end-to-end. Import scanner output, deduplicate and prioritise findings by CVSS severity, track remediation with your clients, and generate compliance-ready reports.
Learn moreRed team reporting platform
The red team reporting platform built for narrative-style operations reporting. Document attack paths with tagging and timelines, coordinate multi-operator engagements, and generate AI-powered narrative reports that tell the full attack story.
Learn moreIncident response
Track incidents from detection through containment, eradication, and recovery. AI-powered triaging categorises and prioritises automatically. Auto-assign to team members with in-app notifications.
Learn moreCompliance audits
Run ISO 27001, SOC 2, and Cyber Essentials assessments with pre-built control templates. Track compliance status, generate AI summaries, and export audit evidence.
Learn moreSocial engineering assessments
Track phishing campaigns, physical access tests, vishing, and pretexting engagements. Document results, generate reports, and deliver findings through your branded portal.
Learn moreSecurity code reviews
Log code-level vulnerabilities with file paths, line numbers, and remediation guidance. Track fixes with developers through the portal and generate technical reports.
Learn moreCyber security assessments
Run comprehensive cyber security assessments and security risk assessments with automated scanning across 16 modules, AI-powered reporting, and professional client delivery, all in one workflow.
Learn moreSecurity testing for web applications
Web application security testing tools with 17 automated modules. Store credentials securely, run comprehensive security tests against authenticated pages, and deliver findings through professional reports.
Learn moreDevSecOps scanning
Connect your Git provider, configure SAST and SCA scanning, and catch security issues before code reaches production.
Learn moreRemediation tracking
Track every vulnerability through the full remediation cycle. Assign owners, set SLAs by severity, collaborate with clients in a branded portal, log retest evidence, and produce a closure record stakeholders can audit.
Learn morePentest project management
Run penetration testing engagements as structured projects. Scope the work, assign your team, track findings live, deliver reports through a branded portal, and bill the engagement from one workspace.
Learn morePurple team operations
Run purple team engagements where the red and the blue side work the same record. Tag every action with MITRE ATT&CK, log detections and gaps in real time, and produce a report that drives detection engineering rather than ending in a PDF.
Learn moreVulnerability disclosure program management
Run a coordinated vulnerability disclosure program (VDP) as an operational workflow rather than an inbox. Capture researcher reports, triage with CVSS, communicate inside a branded portal, track remediation against agreed timelines, and produce a defensible disclosure history aligned to ISO/IEC 29147 and 30111.
Learn moreContinuous penetration testing
Run penetration testing as an always-on programme rather than an annual project. Schedule recurring scans, deliver findings live in a branded client portal, pair retests to original findings, and keep the engagement record open between assessment windows so coverage is continuous and the audit trail is complete.
Learn morePentest retesting
Run retests as a structured part of the engagement. Pair every retest to the original finding, capture fix evidence inside the same record, log regressions when fixes drift, and produce a retest report stakeholders can audit. Stop retesting from spreadsheets.
Learn moreCloud security assessments
Assess cloud security posture with automated scanning for exposed storage buckets, misconfigured services, cloud-hosted web application vulnerabilities, and infrastructure weaknesses. Deliver cloud security services with professional reporting and client portals.
Learn morePentest report delivery
Move pentest report delivery off email attachments and onto a structured workflow. Generate the executive summary, technical report, and remediation roadmap from live findings, deliver through a branded client portal, run a documented debrief, and roll the engagement into retests and remediation tracking on the same record.
Learn moreAPI security testing
Run REST, GraphQL, and OAuth API security testing as a tracked engagement. Store API credentials encrypted, scan authenticated endpoints, log findings against the OWASP API Security Top 10, and deliver retest-ready reports through a branded client portal.
Learn morePentest evidence management
Capture, structure, and retain pentest evidence on the same record the finding lives on. Requests, responses, screenshots, payloads, and proof-of-concept notes stay attached to one engagement timeline. Retest evidence pairs to the original finding so closure is defensible, and the full record exports cleanly when an auditor or client asks for it.
Learn morePentest client onboarding
Stand up a new pentest client without losing a week to email threads, separate intake forms, and credential rummaging. Capture intake, scope, rules of engagement, contacts, credentials, and portal access on the same record the engagement runs on. The client is operational before the test starts, not the day after it ends.
Learn moreThreat-led penetration testing
Run TLPT engagements under TIBER-EU, DORA, CBEST, and iCAST without three separate tools and an inbox of attestation drafts. Manage scoping, threat intelligence input, red team execution, blue team observation, replay, and the joint attestation pack on the same engagement record auditors and competent authorities will eventually read.
Learn moreScanner result triage
Turn raw Nessus, Burp Suite, and SAST output into a clean, deduplicated, severity-calibrated finding list without rebuilding the work each engagement. Triage on the engagement record, validate before the report writes itself, and keep the audit trail intact from import through closure.
Learn moreBulk finding import
Import a backlog of vulnerability findings from Nessus, Burp Suite, prior pentest PDFs, or any CSV onto a single engagement record. Map columns once, deduplicate against the existing catalogue, calibrate severity for the environment, and start working from a clean baseline rather than a spreadsheet stitched together by hand.
Learn moreSecurity testing program management
Run a security testing programme as one record rather than a folder of disconnected reports. Track every engagement across the portfolio, every vendor delivering work, and every asset under coverage; surface findings, retests, SLA performance, and aging risk on one dashboard so the next board update writes itself from delivery rather than from a memory of last quarter.
Learn morePentest retainer management
Run pentest retainer agreements as structured records rather than calendar reminders and a separate spreadsheet of hours. Track the contracted block of hours or test count, draw down each engagement against the master agreement, invoice on the agreed cadence, and keep findings, reports, and the remediation history visible across the full retainer term.
Learn morePentest finding handover to SOC and SIEM
Pentest delivery rarely ends at the report. Validated findings need to land in the client security operations stack with traceability: SIEM detections, SOAR runbooks, ticketing systems, and the asset and risk register. Run the handover from the same engagement record that produced the findings, with severity, evidence, and remediation status preserved end-to-end.
Learn morePentest quality assurance
Run pentest QA on the live engagement record rather than on a Word draft passed around in chat. Reviewers comment against findings, severity calls are challenged with the evidence visible, remediation guidance is verified for developer-readiness, and engagement lead sign-off is captured with a timestamp on the engagement before anything reaches the client portal.
Learn moreSecurity advisory request workflow
Security advisory work sits between the formal pentests. A client asks for a threat model review, a vendor questionnaire response, a pre-launch architecture pass, or an opinion on a control gap. Today that work runs through email, a Slack DM, and an hours spreadsheet that nobody reconciles. Run security advisory requests as structured engagements instead: capture the request through a defined intake, scope the hours, link the work to the parent retainer, deliver the writeup through the branded client portal, and invoice against the agreed cadence. The advisory hours stop leaking.
Learn morePentest vendor panel management
Run a panel of approved penetration testing vendors as a structured record rather than a folder of master service agreements and a memory of who did the last test. Capture each vendor with their capability matrix, status, and performance history; match every new engagement to the right vendor by capability and rotation rule; score delivery against the same criteria across the panel; and walk into the next renewal with the panel evidence the buyer board expects.
Learn morePentest status reporting
The space between kickoff and final report is where most pentest engagements lose client trust. Status reporting fills that gap. Capture coverage progress, in-flight findings, blockers, and the remaining test plan on the engagement record, then publish a structured weekly update through the branded client portal so the client never has to ask where the test stands.
Learn moreCredential handover for pentests
Authenticated pentests live or die on the credentials. Today they arrive on the morning of kickoff in a chat message that nobody can find a week later, get pasted into a tester password manager that the next person on the project cannot read, and survive long after the engagement closes because nobody owned the rotation. Run credential handover as a workflow on the engagement record instead: a defined intake, scoped test accounts, encrypted at rest with AES-256-GCM, role-based access, and a documented rotation at close. The authenticated scan stops being blocked by a missing password and the audit trail captures who held what access and when.
Learn morePentest finding dispute resolution
Most penetration test reports get at least one finding contested. The client says it is a false positive, the severity is too high, the asset is out of scope, the risk is already accepted, or the remediation requirement is unrealistic. Handled badly, the dispute lands in email, drags for weeks, and ends with the firm quietly rewriting a finding nobody can later defend. Handled well, dispute resolution is a structured workflow on the engagement record: triage, evidence review, adjudication against documented criteria, and a captured outcome that holds up six months later when an auditor reads the file.
Learn morePentest tester rotation and handover
Mid-engagement handovers happen for predictable reasons: a tester rotates off a long retainer, takes leave, swaps to a higher-priority engagement, or steps off the project entirely. Handled badly, the new tester inherits a pile of half-documented findings, gaps in the evidence trail, and a client wondering why the cadence has changed. Handled well, tester rotation is a workflow on the engagement record: structured findings carry their own context, evidence sits next to the finding, role-based access transfers cleanly, and the audit trail shows who did what without anyone reconstructing the engagement from memory.
Learn morePentest report version control
Every pentest report has versions: the internal draft, the reviewed draft, the client-issued report, the retest delta, the attestation companion, and any reissue triggered by scope expansion or a contested finding. Run version control on the engagement record so the right version reaches the right reader, the change history survives the engagement, and audit, retest, and attestation reads of the report all line up against the same source of truth.
Learn moreResume a paused pentest
Pause is one half of a two-part workflow. The stop-test letter halts active testing; the resume notice reopens it on conditions both sides have agreed. Run resume on the engagement record so the resume conditions, the partial-scope inventory, the schedule recovery, and the audit trail all sit alongside the original authorisation rather than as a parallel email thread that nobody can reconstruct three months later.
Learn moreVulnerability SLA management
Findings without deadlines are findings nobody finishes. Run vulnerability SLA management on the engagement record so every finding carries a target close date by severity, every breach triggers a defined escalation, and every quarter produces audit-ready evidence of remediation performance. The SLA stops being a slide in a policy document and starts being a column on the queue.
Learn moreVulnerability SLA breach escalation
Every honest vulnerability programme breaches its SLA on some findings. The difference between a programme that survives audit and a programme that fails is whether each breach lands as a governed event on the finding with a named approver, a recorded decision class, a replacement deadline, and a defensible trail of what happened next. Run breach escalation on the engagement record so the chain is automatic, the decisions are constrained, and the evidence does not depend on memory.
Learn moreVulnerability acceptance and exception management
Some findings will not be remediated on the standard SLA. The risk is accepted with a compensating control, the fix is deferred to a planned release, or the remediation cost exceeds the residual exposure. Run the acceptance workflow on the engagement record so every accepted exception carries a named owner, a documented rationale, an expiry date, and a review cadence. Accepted risk that drifts into permanent exposure is the failure mode this workflow exists to prevent.
Learn moreVulnerability prioritisation
A backlog longer than the team can address inside the standard remediation window forces prioritisation. The question is how to prioritise defensibly. Run vulnerability prioritisation on the engagement record so every finding carries CVSS, EPSS, CISA KEV exploitation status, asset criticality, exposure, and compensating controls, and the queue orders itself by real residual risk rather than by creation date or by a single severity number.
Learn moreSecurity leadership reporting
Most leadership decks drift from the operational queue between cycles, and the audit committee ends up reading a different record from the operators. Run security leadership reporting on the same engagement record the team works on so the weekly view, the quarterly leadership pack, and the board briefing all regenerate from one source rather than reauthored by hand.
Learn moreSecurity tool consolidation
Most security programmes accumulate a stack of overlapping tools: a vulnerability scanner, a ticket queue, a shared drive of reports, a compliance spreadsheet, a credential vault, and a chat channel where decisions actually get made. Consolidate that stack onto one engagement record so findings, scans, evidence, decisions, owners, and audit trail live in the same place rather than scattered across systems that never reconcile.
Learn morePatch management coordination
A vulnerability is found by the security team and fixed by the IT or infrastructure team, and the audit reads whichever side recorded it least clearly. Run patch management coordination on the engagement record so patch windows, validation, and post-patch evidence pair to the original finding rather than disappearing into a change ticket the security team cannot read. The patch becomes a closure event on the finding rather than a parallel workstream that has to be reconciled at the end of the quarter.
Learn moreAsset decommissioning and finding retirement
Cloud accounts close, repos archive, domains expire, workloads migrate, services reach end-of-life, and acquisitions consolidate backlogs. Findings on retired assets either inflate critical counts forever or disappear without an audit trail. Run asset decommissioning and finding retirement on the engagement record so every retire event carries a cause, an approver, asset state evidence, and where applicable a successor reference.
Learn moreVulnerability backlog management
Every vulnerability programme accumulates a backlog. The question is whether the backlog is observable, bounded, and on a path to drain, or whether it quietly grows quarter on quarter until risk debt becomes the de facto operating posture. Run vulnerability backlog management on the engagement record so ingest, capacity, aging, and carry-over are visible on the live queue rather than reconstructed once a quarter when leadership asks why nothing is closing.
Learn moreScanner to ticket handoff governance
Most enterprise vulnerability programmes move findings out of the scanner and into a downstream engineering ticket. The handoff is where the audit trail, the severity decision, the evidence, and the closure record drift apart from the security record. Run scanner to ticket handoff governance on the engagement record so the security finding stays canonical, the ticket is a downstream view, and the closure event reconciles back to the original finding without anyone reconstructing it from email threads.
Learn moreControl gap remediation
Most enterprise programmes carry a control gap register that lives in a spreadsheet, drifts between assessments, and only fully reconciles the week before audit. Run control gap remediation as a workflow on the engagement record so each gap has a named owner, a closure plan, evidence requirements, and an audit trail that reproduces from one record rather than from a multi-system reconciliation sprint.
Learn moreSDLC vulnerability handoff
Most product security programmes lose vulnerabilities at the seams between SDLC phases. Threat-modelling notes do not reach the developer. SAST findings do not reach the AppSec triage queue. DAST findings do not reach the platform owner. Pre-production findings do not survive into the operational record. Run SDLC vulnerability handoff governance on the engagement record so each stage gate transfers a versioned set of findings with named owners, evidence, severity calibration, and a reconciliation event that proves the handoff happened rather than dissolving in a hallway conversation.
Learn moreCross-framework control mapping
Most enterprise programmes operate against more than one framework. Without a maintained crosswalk, the same operating control is documented separately for ISO 27001, SOC 2, PCI DSS, NIST, and every sector overlay, and the team scales with the number of frameworks rather than with the underlying programme. Run cross-framework control mapping as a workflow on the engagement record so each internal control carries its citations to every framework it satisfies, every operating evidence artefact is cited from many framework views, version transitions consume as deltas, and sector overlays inherit the baseline.
Learn moreAudit evidence retention and disposal
Evidence retention is the part of compliance operations that fails quietly. Artefacts pile up in a shared drive long past their retention floor, expired evidence is kept indefinitely as legal exposure, fresh evidence is destroyed before its retention window closes, and legal holds either over-retain or get forgotten when the matter resolves. Run audit evidence retention and disposal as a lifecycle workflow on the engagement record so each artefact carries a retention class, a disposition date, a legal-hold flag, and a closure path that the activity log captures with timestamp and user attribution.
Learn moreAsset ownership mapping for findings
Most enterprise vulnerability programmes route findings on the assumption that ownership is already resolved. In practice, asset ownership is the layer that quietly breaks first: a host moves between business units, a repository changes squads, a shared dependency triggers a finding two teams point at. Run asset ownership mapping on the engagement record so the canonical asset identifier, the named owner, the backup, and the escalation chain are queryable from the same record the findings live on.
Learn moreM&A security due diligence
Mergers and acquisitions security due diligence has three operating phases: pre-close target assessment, day-one risk containment, and post-close integration. Every phase has different stakeholders, different access constraints, different deliverables, and different audit expectations. Run all three on the same engagement record so the deal team, the acquirer security team, and the integration owners read from one source rather than three parallel reports that drift the moment the transaction closes.
Learn moreVendor security questionnaire response workflow
When a customer or prospect sends a security questionnaire (CAIQ, SIG Lite, SIG Core, ISO 27001 supplier review, SOC 2 review, NIST 800-171 supplier check, or a bespoke procurement form), the response is a deal blocker that lands on the security team. Run vendor questionnaire response as a structured campaign on the engagement record so the same evidence library, control mapping, finding history, and named-owner routing answer every questionnaire without rewriting the same answers from scratch.
Learn moreThird-party vendor security risk management programme
Vendor security reviews land on the GRC team every new procurement, every renewal, every contract change, every reported vendor incident, and every regulator-driven recertification. Most programmes run them as one-off questionnaires in a shared spreadsheet, lose the prior assessment by the next renewal, and rebuild the same evidence stack from scratch. Run third-party vendor security risk management as a continuous programme on the engagement record so vendor tiering, intake, recertification cadence, attestation freshness, exception lifecycle, incident notification tracking, and exit-and-decommissioning all read against one durable record the audit lookback can reconstruct.
Learn moreAsset criticality scoring
Vulnerability prioritisation depends on a multiplier the queue cannot derive from scanner output alone: how important the underlying asset is to the business. Run asset criticality scoring on the engagement record so every asset carries a tier, a written rationale across data, impact, exposure, controls, recovery, and dependents, and a tier-to-SLA mapping that lets every finding inherit the right deadline at creation.
Learn moreSecret scanning remediation workflow
A leaked secret is not a code-quality finding. It is a live credential an attacker can use until the rotation completes, the old value is revoked, and the verification proves the leak is closed. Run secret scanning remediation as a governed workflow on the engagement record so every detection routes to a named owner, the rotation and revocation are deliberate state events, and the audit trail proves which secrets were exposed, when, for how long, and how the closure was verified.
Learn morePSIRT product security incident response
A product security incident response team (PSIRT) handles every vulnerability that lands against the products the company ships. Reports arrive through the disclosure inbox, the bug bounty platform, the internal scanner queue, the customer escalation channel, the supplier security advisory feed, and the third-party pentest. The PSIRT triages each report, drives the fix, requests a CVE, drafts the security advisory, and notifies the downstream consumers through the agreed channel. Most teams run that lifecycle through email threads, a shared inbox, a confluence page, and a release tracker. SecPortal models the PSIRT case as a structured engagement on the workspace so intake, triage, fix tracking, advisory drafting, audit trail, and downstream publication share one source of truth.
Learn moreDependency vulnerability triage
A new SCA scan can ship 40 critical CVEs in a single dependency tree. Most of them are not reachable from the application, several are already patched in a transitive update, a few are exploitable in the deployed environment, and one is the actual fire. Programmes that treat every dependency CVE as critical burn the engineering team and ignore the real risk. Run dependency vulnerability triage as a governed workflow on the engagement record so each finding is classified by reachability and exposure, the routing decision lands on a named owner, the closure is verified by a re-scan, and the audit trail proves which CVEs were prioritised, why, and how the closure happened.
Learn moreZero-day and emergency vulnerability response
A new critical CVE drops on a Friday afternoon. CISA adds a third-party library to the KEV catalog. A vendor publishes an emergency advisory with active exploitation in the wild. Internal security teams scramble to answer four questions in parallel: which assets are exposed, who owns the fix, what does proof of remediation look like, and how do we evidence the response to leadership and to the next audit. Most teams answer those questions through a hastily-created Slack channel, a shared spreadsheet, an email thread to engineering, and a war-room meeting that nobody minutes. Run zero-day and emergency vulnerability response as a structured engagement on the workspace instead, so the exposure assessment, the prioritised remediation, the verification, and the audit evidence land on one record from CVE drop to verified closure.
Learn moreCyber insurance security evidence
Cyber insurance underwriters and brokers no longer treat the security questionnaire as a checkbox exercise. Application questionnaires, mid-term renewal questionnaires, and post-incident claim assessments all expect proof that the security programme operates the controls the policy is priced against. Most teams answer those questionnaires from memory, then assemble screenshots, scanner exports, and policy PDFs at renewal week. Run cyber insurance security evidence as a structured workflow on the live engagement record so underwriting evidence, renewal evidence, mid-term attestations, and claim evidence all derive from the same source the operators run on.
Learn moreNew application security onboarding
New applications enter the estate constantly: a new product line, a spin-out service, a new vendor-acquired component, a SaaS tenant launched off the platform, or a repo a team forked into a new service. Most security programmes meet these applications later than they should, after a scanner, an audit, or a customer questionnaire surfaces the gap. Run new application security onboarding as a structured workflow on the engagement record so every new service enters the programme with a documented baseline (threat model, code scan, baseline DAST, owner mapping, evidence trail) rather than appearing in the backlog months after launch with findings already aged.
Learn moreBreach notification and regulator readiness
Most security organisations operate breach notification as a series of last-minute decisions across email, chat, and a legal-team Word document. The clocks (GDPR 72 hours, NIS2 24 and 72 hours, SEC four business days, HIPAA 60 days, DORA initial and intermediate windows, state law variations, PCI DSS account data compromise rules) keep running while the disclosure committee reconstructs what was known, when it was known, and who decided what. Run breach notification and regulator readiness as a structured workflow on one engagement record so every notification clock, materiality determination, evidence artefact, and disclosure decision lands on the same trail the regulator, the auditor, and the audit committee can read against later.
Learn moreThreat intelligence driven vulnerability prioritisation
Most vulnerability programmes consume threat intelligence by reading the CISA KEV catalog every morning and forwarding interesting CERT advisories into Slack. The intel arrives, but the prioritisation queue does not change. Run threat intelligence driven vulnerability prioritisation as a structured workflow on the engagement record so every CTI signal (KEV listing, EPSS percentile shift, CERT or vendor advisory, ISAC bulletin, internal red team finding, sector-specific exploit chatter) is ingested as an explicit input, fitness-assessed against the in-scope estate, converted into a recorded prioritisation action with a named decider, routed to the named owner, and fed back into the next ingest cycle on the same trail the auditor and the audit committee read.
Learn moreCustomer security evidence room workflow
B2B SaaS security teams field a recurring exercise: a customer security reviewer asks for the SOC 2 report, a prospect runs a TPRM review, a renewal cycle reopens the questionnaire backlog, a regulator-driven assessment rides through a customer relationship, and the internal team rebuilds the same evidence packaging from scratch each time. Run the customer security evidence room as a structured workflow on a customer engagement record so every release is a recorded action, every artefact carries an effective date, every NDA gates the release rather than the conversation, and every access scope has a named revocation owner.
Learn moreInternal developer platform security guardrails
Internal developer platforms succeed when the secure choice is the default and the insecure choice requires an explicit, audit-trailed override. Run paved-road security guardrails on a single engagement record so registration, scanner coverage, build provenance, deployment gates, severity recalibration, and exception expiry are queryable rather than scattered across pipelines, scanner tools, ticket systems, and chat threads.
Learn moreContinuous Threat Exposure Management
A CTEM cycle is the programme layer that bounds continuous exposure work into a defined scope, deduplicated Discovery, defensible Prioritisation, first-class Validation, and Mobilisation closure that hands residual work into the next cycle. Run the cycle on the engagement record so scope, discovery coverage, prioritisation rationale, validation evidence, and closure summary derive from the same source the team operates against, rather than from a folder of attachments and three parallel scanner extracts.
Learn moreSecurity finding evidence package
Most security findings reach developers as a one-line description, a CVSS number, and a screenshot. Developers spend the next two days reproducing the issue, asking the security team to clarify scope, and guessing what acceptable fix evidence looks like. Run security finding evidence packaging on the engagement record so each finding ships to engineering with the reproduction steps, the request and response, the affected asset and code path, the calibrated severity, the fix expectations, the retest criteria, and the audit trail attached as one structured record. The remediation conversation starts on the evidence rather than on the rediscovery.
Learn moreThird-party penetration test report intake
Most internal security teams treat the third-party pentest report as a deliverable to file and a list of action items to forward. Run pentest report intake on the engagement record so each finding becomes a structured remediation work-item with calibrated severity, dedup against the existing scanner catalogue, named owner from the asset ownership map, SLA clock on assignment, retest evidence bound to the original finding, and a one-record audit chain. The PDF survives as audit evidence; the queue runs against findings.
Learn moreSBOM management and VEX publishing
Most enterprise programmes treat the Software Bill of Materials as a procurement deliverable and file it the moment the customer questionnaire reply ships. When a high-profile CVE drops against a transitive component, the exposure question becomes a reconstruction project rather than a query. Run SBOM management and VEX publishing on the engagement record so generation, ingestion, asset binding, vulnerability matching, VEX status assertion, and downstream delivery to customers and auditors land on one source rather than across a folder of attachments.
Learn moreAudit fieldwork evidence request fulfillment
Audit fieldwork lands as a list of fifty to four hundred evidence requests with a fourteen-day clock. Most internal security and GRC teams run the response from a shared spreadsheet, an email inbox, and three Slack channels. Evidence stalls on the wrong owner, samples drift between what the auditor asked for and what the team produced, the same artefact is re-pulled because the prior response is invisible, and the audit closes with carry-forward observations no one expected. Run audit fieldwork evidence request fulfillment as a structured workflow on the engagement record so each PBC request becomes a tracked item with a named owner, a documented sample scope, a captured response, and an activity log entry that the auditor reads against the same record the security team operates against.
Learn moreVulnerability finding intake
Internal security, AppSec, and vulnerability management teams take findings from many sources: external scans, authenticated DAST, code scanning, manual pentest entry, third-party reports, bug bounty submissions, security advisories, and ad-hoc developer escalations. Most programmes accept all of it through a shared inbox, a triage spreadsheet, and three Slack channels. Findings land with inconsistent severities, ambiguous asset bindings, and no owner of record; the first triage cycle re-keys what the source already said; duplicates compound. Run vulnerability finding intake as a structured workflow on the workspace so every inbound finding lands with normalised metadata, a named owner at the door, deduplication against the existing catalogue, and an activity log entry that survives into remediation, retest, and audit.
Learn moreVulnerability fix verification
Internal security, AppSec, and vulnerability management teams close hundreds of findings a quarter. Most close on a developer marking a ticket "done" with no reproducible proof that the original attack path no longer works. The closed-count looks good; the next scan reopens half of them; the auditor reads the activity log and finds a status change with no evidence of verification. Run vulnerability fix verification as a structured workflow on the workspace so every closed finding carries a reproducible proof-of-fix, a regression check, an attached evidence artefact, and an activity log entry that survives into the next audit cycle.
Learn moreContainer image vulnerability remediation
A single new image scan can ship sixty CVEs against the base layer, twenty against the application libraries, a handful against vendored binaries, and a dozen Dockerfile rule failures. Many close on an upstream advisory rather than on the deployed image; many close on a base-image rebuild that the dependent services never inherit; many close on a merged pull request that lands on a branch the production stream does not run. Run container image vulnerability remediation as a rebuild-and-redeploy workflow on the engagement record so every finding carries an image-digest binding, a source-class attribution, an asset fan-out across consuming services, a named rebuild target, and a closure scan against the post-rebuild image digest. AppSec, product security, cloud security, vulnerability management, platform engineering, and security engineering teams read the same record across the rebuild and the verification.
Learn moreVulnerability finding state lifecycle
Every vulnerability finding moves through a state lifecycle: open, in progress, resolved by an engineer, verified by retest, sometimes reopened on a regression, eventually closed with the proof attached, or set false positive when reproduction fails. Most programmes run this in a spreadsheet where the cell colour is the state and the audit trail is a Slack search. Run the state lifecycle as a defensible workflow on the workspace: explicit status transitions on the finding record, named actors on every change, evidence captured at each transition, and an activity log that survives from intake through audit.
Learn moreSecurity finding ownership and routing
Most programmes decide who owns each vulnerability finding through chat, default-assignee rules, or analyst memory. The routing record never lands on the finding, the audit trail is a Slack search, and the unowned-finding tail grows quietly. Run ownership and routing as a defensible workflow on the workspace: ten deterministic routing rules read against six dimensions (asset binding, source class, severity, engagement type, asset criticality, cross-team scope), eight operating queues for unassigned, acknowledgement-pending, reassignment, cross-team, escalation, disclosure, source-class, and policy-violation work, and an activity log that captures every assignment, reassignment, acknowledgement, and escalation event with the named actor and the routing rule cited.
Learn moreVulnerability finding CVE and EPSS enrichment
Most programmes inherit findings from scanners with a CVSS number and nothing else: no CVE on the record, no EPSS percentile refreshed against the daily FIRST feed, no CISA KEV reconciliation against the catalog refresh, no vendor PSIRT bulletin reference, and no clear treatment for the long tail of findings that never carry a CVE. Run enrichment as a defensible workflow on the workspace: six upstream signals captured against every finding (CVE identifier, CVSS 3.1 vector, EPSS probability and percentile, KEV catalog status, CWE classification, vendor advisory reference), five enrichment tiers the queue resolves into (fully enriched, partial enrichment, no applicable CVE, stale enrichment, enrichment conflict), and an activity log that captures every refresh, reconciliation, and calibration decision.
Learn moreSecurity debt portfolio management
Most security programmes treat every open finding as one undifferentiated queue: a fresh critical from yesterday sits next to a medium that has been carried for eighteen months on a compensating control nobody has re-validated. The queue reads as a single number, the leadership pack reports a single backlog total, and the audit cycle asks why the same findings appear cycle after cycle. Run security debt as a portfolio: four debt classes captured against every aged finding, named owners on each debt tranche, an explicit carrying cost per tranche, a published burn-down plan tied to budget cycles, and an activity log that captures every reclassification, write-down, and re-acceptance decision on the engagement record.
Learn moreSecurity finding translation
A finding leaves security in CWE, CVSS, and scanner shorthand and arrives at engineering as an abstraction the developer has to decode before the fix can start. Run security finding translation on the engagement record so each finding ships to engineering with the concrete sentence-form description, the calibrated severity rationale, the engineering coordinate of the affected location, a runnable reproduction script, a verifiable fix expectation, and named acceptable closure evidence attached as one record. The remediation conversation starts on the translated finding, not on the rediscovery.
Learn moreSecurity finding reopen and regression handling
Closed findings reopen. A scanner re-detects on the next cycle, a retest comes back failed, a partial fix leaves residual variants on the same CWE, a dependency downgrade reintroduces a vulnerable package, a configuration drift undoes the hardening, a watch window expires, or a dismissed false positive turns out to be real. Run reopen and regression handling on the engagement record so each return event reopens the original finding ID with the regression class, the lineage to the prior closure, the restored severity, the named owner of the new cycle, the reopen-SLA target, and the activity-log stamp. The chronology stays one continuous record across closure cycles rather than splitting into parallel tickets the leadership report cannot reconcile.
Learn moreCross-engagement finding search
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.
Learn moreVulnerability finding merge and supersede workflow
Consolidate duplicate vulnerability finding records into one identity-coherent record without losing the closure narrative, the audit trail, or the queue position. The workflow runs on the workspace findings view with status group, severity, and substring filters surfacing the duplicate candidates, the finding state model carrying the closure states the supersession uses, the finding overrides primitive holding the durable upstream suppression for recurring scanner re-detections, and the activity log capturing every merge decision as a named operational action.
Learn moreCSPM finding remediation workflow
Cloud security posture management tools surface thousands of misconfiguration findings across AWS, Azure, GCP, and Kubernetes accounts. Run those findings through a single engagement record so intake, deduplication, severity calibration, owner routing, exception expiry, retest verification, and audit evidence land in one place rather than fanning out across the CSPM console, the ticketing queue, the chat thread, and the spreadsheet.
Learn moreTLS certificate expiry and lifecycle tracking
Expired and misconfigured TLS certificates take production down, break customer authentication, and surface as audit findings against ISO 27001, SOC 2, and PCI DSS cryptographic controls. Run certificate lifecycle as a vulnerability discipline on the engagement record so the cert inventory, the upcoming-expiry queue, the renewal trail, and the chain-health evidence live in one place rather than in a script, a spreadsheet, and three calendars nobody owns.
Learn moreSecurity vendor disclosure coordination
When your AppSec, product security, or security engineering team finds a vulnerability in an external software vendor product, run the disclosure coordination as a structured engagement rather than as a one-off email thread. Track vendor contact, acknowledgement, triage, embargo, CVE assignment, advisory publication, and company-side remediation on one record. The closure history holds up under audit, customer assurance review, and your own published disclosure policy.
Learn moreCyber risk quantification evidence loop
Cyber risk quantification programmes turn vague risk language into loss exposure ranges that the board, the audit committee, the underwriter, and the regulator can read against the financial statements. The discipline lives or dies on whether the loss event frequency, threat event frequency, vulnerability, and loss magnitude inputs reconcile to the operating record the security team runs on day to day. Most programmes maintain CRQ in a parallel FAIR spreadsheet, refresh it quarterly from memory, and lose the audit trail between cycles. Run the cyber risk quantification evidence loop on the same engagement record the vulnerability programme, the exception register, the audit-evidence retention workflow, and the leadership cadence already use so each scenario input regenerates from the source the security team operates on rather than from a separate document.
Learn moreVulnerability remediation campaign management
Sometimes the queue needs more than steady-state remediation. A regulatory mandate names a fix deadline. A risk-register review surfaces a class of findings that has aged out. A new control owner inherits a backlog that needs draining before the next audit. Engineering wins a window for a library upgrade that touches dozens of services. The right answer is a time-boxed remediation campaign: a defined cohort of findings, named owners across teams, parallel work streams, a daily cadence, mid-campaign re-prioritisation, and a verification pass that turns campaign closure into evidence rather than assertion. Run the campaign as a structured engagement on the workspace so the cohort scope, the owner assignment, the work-stream status, the verification scans, and the post-campaign report all land on the same record.
Learn moreKubernetes security finding remediation workflow
Kubernetes findings arrive from a wider surface than container images alone. KSPM tools surface cluster posture against CIS Kubernetes benchmarks and Pod Security Standards. RBAC audits flag over-permissive role bindings and dormant service accounts. Admission controllers (Kyverno, OPA Gatekeeper, native PSA) reject or warn on workloads that miss policy. Network policy reviews surface missing default-deny and cross-namespace exposure. Workload runtime scans flag privileged containers, hostPath mounts, hostNetwork, hostPID, and capability drops. The cluster team, the platform engineering team, the AppSec team, and the namespace owners each see a slice. The right operating model is one engagement record per cluster scope that holds the finding lifecycle across all of these inputs so deduplication, calibration, routing, exception expiry, and retest verification read off one surface rather than from five vendor consoles.
Learn moreSecurity finding data quality and completeness workflow
Vulnerability programmes accumulate dirty finding data faster than they remediate. Severities arrive blank, categories drift to free text, affected asset fields point at deleted hostnames, owners no longer work at the company, CVSS vectors are missing on findings that have a score, control references are inconsistent across engagements, and duplicate identities sit in the queue under different titles. The audit lookback reads from the same record set, the leadership posture read reads from the same record set, and the SLA calculation reads from the same record set. Run finding-record hygiene as a recurring workflow on the workspace findings view so the data quality of the inventory is a deliberate operating discipline rather than the residue of every ingestion cycle.
Learn moreSaaS security finding remediation workflow
SaaS findings arrive from a wider surface than the SSPM console alone. Dedicated SSPM platforms surface tenant misconfigurations. SaaS-native posture surfaces (Salesforce Security Center, Google Workspace Alert Center, Microsoft 365 Defender for Cloud Apps, Atlassian Access) flag rule violations from inside the tenant. Identity governance tools surface access review items and joiner-mover-leaver lifecycle failures. OAuth grant inventory engines flag overscoped consent, dormant integration, departed-user retention, and third-party vendor exposure. CASB exposure feeds surface public sharing links, anomalous downloads, and shadow SaaS data egress. Manual reviews, third-party SaaS pentests, and vendor questionnaire responses add human review. The right operating model is one engagement record per SaaS tenant (or per business owner for dense long-tail SaaS) that holds the finding lifecycle across all of these inputs so deduplication, calibration, routing, exception expiry, and retest verification read off one surface rather than from five vendor consoles.
Learn moreInternal vulnerability disclosure intake
Internal security teams operate two front doors. The external vulnerability disclosure programme publishes the public rules for researchers and customers; the internal vulnerability disclosure intake holds the channels and discipline for reports that originate inside the organisation. Reports arrive from named employees through the security inbox, from developers escalating through engineering chat or pull request review, from customer-success agents forwarding security-relevant tickets, from the internal red team or in-house pentest function, from bug bounty triage handoffs landing for internal remediation, from awareness exercise outputs, from compliance and legal cross-function escalations, and through the corporate anonymous reporting channel. Run the workflow as a structured intake on the workspace so every inbound report lands on an engagement record with a captured channel, an acknowledgement to the reporter, an asset binding, a named owner of record, a normalised severity, a dedup check, an exception register check, and an activity log entry that survives into remediation, retest, and audit.
Learn moreVulnerability SLA breach recovery
Vulnerability SLAs breach. The honest enterprise programme accepts that and runs a structured recovery loop after every breach event rather than treating the breach as a one-time incident that closes once the engineer ships the fix. Stabilise the breach, classify the cause against a canonical taxonomy, run the recovery against a plan, verify the fix, and file a post-mortem with a corrective action read against breach recurrence per cause class.
Learn moreSecurity incident evidence handover
An incident closes for the security operations team when the threat is contained, the system is restored, and the timeline is reconstructed. It does not close for the rest of the organisation. Counsel still needs the privileged chronology and the evidence references. The GRC team still needs the control-effectiveness reads for the next audit. The audit committee still needs the disclosure-grade narrative. The insurer still needs the carrier-format evidence package. The board still needs the leadership read-out. The regulator-relations function still needs the regime-specific filing pack. The downstream remediation owners still need the corrective action ledger with named owners and target dates. Run the security incident evidence handover as a structured workflow on the engagement so every recipient gets the right package, signs an acceptance, and the original record holds the trail of who received what and when. The handover is the bridge between the live incident engagement and the seven or eight downstream operating cycles the incident actually feeds.
Learn moreEmerging vulnerability and CVE watch
Most CVE noise is irrelevant to most programmes most of the time. The few CVEs that matter to your deployed estate need to surface before the next scheduled scan would have found them, and they need to convert into in-scope findings on the engagement record rather than into a chat post that nobody is required to act on. Run the CVE watch as a structured weekly program: ingest CVEs and vendor advisories from the canonical feeds, run a fitness assessment against the connected repositories and the verified domain inventory, convert the in-scope CVEs into findings on the engagement record with provenance attached, and read a recurring coverage view so the watch program itself stays defensible at audit.
Learn moreBug bounty finding intake and triage
Bug bounty submissions arrive through HackerOne, Bugcrowd, Intigriti, Synack, or a private programme; the external platform brokers the researcher relationship and the payout. The work the security team still owns is internal: validate the report against the deployed estate, dedup against existing findings, calibrate severity to the programme standard, route to the named owner, retest the fix, and produce the audit evidence the GRC team carries through ISO 27001, SOC 2, PCI DSS, NIST 800-53, NIS2, and DORA fieldwork. Run that internal record as a structured intake and triage workflow on the same engagement surface the rest of the vulnerability programme uses.
Learn moreAPI security posture assessment workflow
Most enterprise teams run API security as a series of one-shot pentests against individual APIs. The audit chain expects more: an estate inventory, schema and specification governance, authenticated coverage per API, a consolidated finding catalogue across scanners and reviews, an exception lifecycle, change-event detection, programme metrics, and a recurring audit-evidence pack. Run API security posture as a programme cycle on one engagement record so the operating loop reads against a live record between cycles rather than reconstructing the posture at audit week.
Learn morePost-incident lessons-learned workflow
Most security teams run the post-incident review as a meeting and produce no durable artefact. The audit chain expects more: a chartered postmortem, an activity-log-based timeline reconstruction, a contributing factor register, a corrective action ledger with named owners and verification methods, a control-improvement queue tied to compliance framework records, a recurring failure-mode catalogue, a published lessons register, and an audit-evidence pack assembled from the live record. Run the discipline on the workspace so the operating signal between incidents reaches the next audit, the next engagement, and the next leadership read.
Learn moreVulnerability management program onboarding
Most internal security teams launch a vulnerability management programme as a slide deck, a kickoff meeting, and a tracking spreadsheet. The audit chain expects more: a chartered programme record, a named scope and asset map, a published SLA policy, a documented exception register, a named RACI, a first scan baseline, a leadership read cadence, and an audit-evidence pack assembled from the live operating record. Run the onboarding as a structured engagement on the workspace so the discipline that operates the programme on day 91 is the same discipline the audit chain reads against in cycle one.
Learn moreSecurity finding disposition meeting
Most internal security, AppSec, and vulnerability management programmes reach a queue too long for per-finding decisions and a chat channel too thin for the next audit. The disposition meeting is the recurring governance forum that batches the cohort needing a decision, runs each through a documented set of disposition options, and writes the outcome onto the workspace finding record so the activity log carries the named approver, the rationale, the expiry, and the chronology the audit chain reads against.
Learn moreSecurity team on-call rotation
Most internal security, AppSec, PSIRT, vulnerability management, and security engineering programmes reach a point where the inbound event volume exceeds business hours. Run the rotation as a chartered engagement on the workspace with a named primary, a named secondary, a published escalation authority chain, a structured handover at each shift change, and the activity log capturing the named operator at every event. The discipline that holds the shift on a Tuesday morning is the same discipline the next audit reads against ISO 27001 Annex A 5.24, SOC 2 CC7.3, PCI DSS 12.10, NIST CSF 2.0 RS.MA, NIS2 Article 23, and DORA Article 17.
Learn moreScanner onboarding and coverage rollout workflow
Every internal security, AppSec, vulnerability management, cloud security, and security engineering programme reaches the point of bringing a new scanner online. The pilot fires false positives, the coverage map is incomplete, the severity defaults do not match the workspace policy, the owners are not yet routed, and the audit cycle that follows the rollout has no defensible record of how the scanner got from pilot to production. Run the rollout as a chartered engagement on the workspace with a documented pilot scope, structured coverage phases, calibrated severity normalisation, named owner routing, an exception register filter, and an activity-log trail that the next audit reads against rather than a folder of one-off screenshots.
Learn moreSecurity feature launch readiness evidence pack
AppSec, product security, and security engineering teams meet feature launches dozens of times a release cycle. Each launch needs a defensible answer to the same questions: what changed in the threat model, which baseline scans ran against the change, which findings still sit open at ship time, what exception decisions absorb residual risk, and who signed the launch gate. Run launch readiness as a per-feature workflow on the engagement record so the evidence pack assembles from live workspace data rather than from a slide deck a security lead writes once and never references again.
Learn moreAudit walkthrough and control narrative evidence
SOC 2 Type 2, ISO 27001 surveillance, PCI DSS assessments, NIST SP 800-53 reviews, and internal audits all open the same way: the auditor reads a written description of each control (the control narrative) and then sits with the control owner to watch the control run end to end on one real record (the walkthrough). Most internal security, GRC, and compliance teams reauthor the narratives every cycle, rehearse walkthroughs from memory, capture nothing structured about who demonstrated what, and lose the chronology between cycles. Run the audit walkthrough and control narrative workflow on the engagement record so each narrative is a versioned artefact, each walkthrough is a recorded demonstration with named attendees and a documented step sequence, and the next cycle reads against a defensible prior instead of rebuilding from a fresh spreadsheet.
Learn moreVulnerability exception renewal and expiry pipeline
Most vulnerability programmes record the initial exception decision well, then leave the register alone until the audit asks. Expiry dates pass without renewal decisions, compensating controls age out without re-validation, named owners leave the workspace, framework citations age, and the underlying finding severity is revised upward without the residual risk being re-attested. Run the renewal and expiry pipeline on the engagement record so each active exception surfaces every trigger that should prompt a renewal review, every renewal review reads against the current state, and expired-without-action exceptions land in a documented recovery queue rather than surfacing as fresh findings in the open queue.
Learn moreSecurity finding evidence pack handoff to internal audit
Internal audit reads the cyber programme on a different beat than the security team operates it. The audit team scopes engagements quarterly or half-yearly, samples findings against documented criteria, tests operating effectiveness against the named control, and writes working papers the audit committee reads. Most second-line security and GRC teams hand evidence over in an unstructured push: a CSV pulled to an internal audit request, a screenshot of the open queue, a slide deck for the audit committee, and a separate conversation about exceptions. The pack drifts between handovers, the chief audit executive cannot tell which findings were sampled previously, and the next audit cycle re-pulls raw artefacts that should have been continuous. Run the security finding evidence pack handoff as a structured periodic workflow on the engagement record so the audit team receives a versioned pack with documented sample criteria, named control coverage, an exception register with current attestations, and an activity-log trail that preserves independent retesting on the same record.
Learn moreVulnerability finding data export and warehouse ingest
The operational security workspace records findings, engagements, scans, exceptions, retests, reports, and the activity log every day. The leadership dashboard, board cyber risk briefing, multi-cycle remediation throughput trend, framework attainment tile, and cyber risk quantification loss curve read the same record on different cadences and join shapes through the enterprise data warehouse. Most security programmes pull a CSV once a quarter, the chart drifts from the workspace, and the leadership read disagrees with the working dashboard. Run vulnerability finding data export and warehouse ingest as a documented pipeline: cadenced exports of well-defined classes, named service accounts, documented landing zones, a schema contract the warehouse loader can rely on, and a data classification rule that keeps sensitive columns out of the wrong environment. SecPortal does not ship native warehouse, BI, ELT, ticketing, SIEM, SOAR, or GRC platform connectors; the export classes are existing CSV and Excel pulls the security data engineering function loads on its own pipeline.
Learn moreCloud security finding prioritisation
CSPM, IaC scanner, external scanner, and authenticated scanner output a queue that, sorted by CVSS alone, treats a multi-account cloud estate as uniform. A privilege escalation on an isolated sandbox cluster reads at the same priority as a privilege escalation on the production payments cluster. Calibrate each cloud finding against six blast-radius dimensions (identity reach, network exposure, data classification, workload tier, lateral movement reach, recovery profile) and record the calibrated priority with cited rationale on the engagement record. The queue ordering becomes a derivable property of the resource context, the leadership view reads the weighted exposure rather than the unweighted open count, and the audit lookback reads a defensible prioritisation trail. SecPortal does not ship native CSPM, identity-graph, Jira, ServiceNow, SIEM, SOAR, GRC, SSO, or SCIM connectors; the calibration runs on the workspace engagement record, finding overrides, activity log, and AI report generation surfaces.
Learn moreSOC to vulnerability management handoff
Security operations sees signal the vulnerability management programme would never see alone: a missed patch exploited in the wild, a default credential reached over the network, a misconfigured cloud bucket touched by an unknown identity, an outdated dependency exercised by a real payload, an exposed admin interface scanned by an attacker before any cycle picked it up. When the response closes, the underlying vulnerability class often stays open because the handoff to vulnerability management never happens or happens in chat. Run the SOC to vulnerability management handoff as a structured workflow on the workspace so every detection that surfaces a vulnerability class crosses the boundary as a finding with provenance, calibrated severity, asset binding, named owner, evidence chain, and an audit trail that survives long after the incident is closed. SecPortal does not ship native SIEM, EDR, MDR, XDR, SOAR, or ticketing integrations; the handoff runs on findings management, engagement records, bulk finding import, activity log, finding overrides, retesting workflows, and AI report generation.
Learn moreReady to run your workflow on SecPortal?
Start free. Set up your workspace in under two minutes.
No credit card required. Free plan available forever.