Use Case

Internal vulnerability disclosure intake
a trusted front door for security reports that start inside the organisation

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.

Get Started Free

No credit card required. Free plan available forever.

A structured front door for security reports that start inside the organisation

Internal security teams, AppSec teams, product security teams, and vulnerability management teams operate two front doors at once. 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. Internal 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. Most programmes accept all of it through a shared security@ alias and a Slack channel that the rotating on-call reads when they can. The upstream is the difference between a queue that reads defensibly and a queue that absorbs whatever lands.

The workflow composes with the rest of the vulnerability management operating model. The broader vulnerability finding intake workflow covers every source across the queue; this workflow is the subset focused on internally-originated human-reported channels. The external-facing vulnerability disclosure programme management workflow is the outward-facing counterpart for external researchers and customers. The product-vendor side runs through the PSIRT workflow for issues against shipped products. The downstream scanner result triage workflow and prioritisation workflow read the normalised intake queue to decide what gets validated and worked next. Internal disclosure intake sits at the upstream as the discipline that decides what enters the queue from inside the organisation and on what terms.

Eight internal channels every enterprise programme has to accept on documented terms

Most enterprise security programmes accept internally-originated reports from the same recurring set of channels. Each channel has its own capture style, its own native context, and its own intake treatment. The register makes the channels explicit so the intake check verifies the report came from an accepted channel rather than from a freeform thread the operating record does not know about.

Internal channel	What the channel captures	How the workflow handles it
Internal security inbox (security@, secalerts@, security-reports@)	The named mailbox the organisation publishes internally for employees, contractors, and named partners to raise security concerns. Reports arrive as freeform email with mixed structure: a developer noticing a debug endpoint exposed in staging, an SRE flagging a misconfigured S3 bucket, a customer-success agent forwarding a security question from a customer ticket, a release manager reporting a credential checked into a branch.	A named on-call security operator opens each inbound message as an engagement against the relevant application or service record. The original email body, the sender, the timestamp, the affected asset where derivable from the body, and any attached evidence are captured on the finding so the audit trail starts at the report rather than at the first triage note. The reporter receives an acknowledgement notification with the assigned reference within the documented acknowledgement window so the chain of communication has a structured starting point.
Developer escalation through engineering chat or pull request review	Findings raised by a software engineer, platform engineer, or SRE who noticed a security-relevant issue while working on a feature, reading a pull request, or operating the production service. The escalation often arrives as a short Slack or Teams message in an engineering channel, a comment on a pull request, or a direct message to a security team member.	The receiving security operator pastes the escalation into a manual finding entry against the relevant engagement, captures the affected repository or service, the named reporter, the description, and the suggested severity. The intake check verifies this is a security issue rather than a feature request and that the asset binding is correct before the finding opens on the queue. The chat thread or pull request reference is recorded on the finding as the source so the chronology is reconstructable.
Internal-customer escalation (customer success, support, account management)	Security concerns surfaced to security by an internal team after a customer raised the issue externally. Customer success agents forwarding a customer ticket flagging suspicious behaviour, account managers passing along a customer report about leaked credentials, or support engineers escalating a customer complaint about session bleed. The original reporter is the customer; the inbound channel into security is internal.	The intake captures the customer reference (without exposing identifying detail beyond what the operational record needs), the receiving internal team, the original customer report body, the affected product surface, and the suggested severity. The finding opens against the product engagement record. If the report requires customer-facing communication, the workflow links the customer escalation thread to the engagement record so the response routes back through the same channel rather than fragmenting into a parallel email thread.
Internal red team, internal pentest, and security review findings	Findings produced by the internal red team, the in-house penetration testing function, security architecture reviews, threat models, secure code reviews, or tabletop exercises that surface a vulnerability needing remediation. The work was authorised by the security programme, the engagement scope was documented, and the finding lands as a structured writeup rather than as an unstructured report.	The internal tester opens a manual finding entry against the engagement that authorised the work, selects the relevant remediation template, attaches the evidence (proof of concept, screenshot, request/response, log excerpt), calibrates severity against the asset criticality, and writes the technical description. The intake check verifies the engagement scope and the rules of engagement permitted the work that produced the finding. The internal tester is captured as the named reporter on the activity log.
Bug bounty triage handoff for internally-reproduced reports	Reports that arrived through the external bug bounty platform or coordinated disclosure programme, were triaged externally as valid, and are being handed to the internal security team for remediation tracking. The external researcher relationship lives on the bug bounty platform; the internal remediation record lives in the workspace. The handoff brings the validated report into the operating queue.	The internal triager opens a manual finding entry against the engagement, captures the external report reference (bounty platform case ID, disclosure submission ID), the external researcher attribution, the reproduced severity, the proof of concept, and the requested handling. The intake records the source attribution explicitly so the audit trail reads that the finding came through the external programme but is being worked through the internal remediation queue. Findings remain linked to the original external case so disclosure timing, public communication, and credit handling stay coordinated.
Security awareness training, phishing simulation, or tabletop output	Findings raised when a security awareness exercise surfaces a concrete vulnerability rather than a training metric. A phishing simulation that succeeds because a real OAuth grant was misconfigured, a tabletop exercise that exposes a missing runbook covering a real attack path, or a training session where a participant reports a real issue they had been carrying.	The exercise lead opens a manual finding entry against the relevant engagement (the training programme engagement or the operational programme engagement), captures the exercise context, the named participant where relevant, the affected asset or process, and the suggested severity. The exercise output stops living only on the awareness dashboard and joins the operational record so remediation can be tracked rather than aggregated into a metric.
Compliance, audit, legal, or HR escalation (privacy incident, regulator query, contract review)	Findings that landed with security through a non-technical internal function. The privacy team noticing PII flowing to a logging surface it should not be on; legal reviewing a customer contract and flagging a security commitment the product cannot meet; HR escalating a departing employee scenario with access-control implications; audit highlighting a control gap mid-fieldwork that the remediation queue should carry rather than only the audit report.	The security operator opens a manual finding entry against the relevant engagement, captures the originating internal function, the named contact for follow-up, the affected asset or process, the framework or regulatory reference where one applies, and the suggested severity. The cross-function nature of these reports is captured on the engagement so the named owner and the named legal/privacy/audit/HR contact stay paired on one record rather than fragmenting into parallel reporting chains.
Anonymous internal reporting channel (whistleblower, ethics line, internal speak-up)	A subset of internal reports arrive through the corporate anonymous reporting channel (the whistleblower line, the ethics hotline, the internal speak-up portal) and reach security because the underlying concern is a security or privacy issue rather than an HR or financial-conduct concern.	The intake honours the anonymity protections the originating channel guarantees. The security operator captures the report content, the affected asset where derivable from the body, and the suggested severity on a finding record without identifying the reporter beyond what the anonymous-channel governance permits. The originating channel governance, the reporter-anonymity policy reference, and the named non-reporter contact stay attached so the chronology is auditable without exposing the protected identity.

Seven failure modes that quietly break internal vulnerability disclosure intake

Internal-disclosure failure usually looks like sensible defaults: a shared inbox, an ad-hoc rota, no formal acknowledgement, no asset binding at the door. The cost arrives weeks later as a front door reporters stop trusting, a queue the team cannot prioritise, and an audit that cannot reconstruct the chronology from report to closure.

Reports live in the security inbox and never reach the operating record

The internal security inbox is read by whoever is on the rota that week. Reports get acknowledged in email but never opened as findings; the email thread becomes the operational record by default. Three weeks later the original reporter follows up and nobody on the team can locate the report. The fix is opening every actionable internal report as a structured finding against the engagement record on the same day it arrives, so the operating queue is the canonical source rather than the inbox.

Acknowledgement is implicit and the reporter loses confidence in the channel

A developer reports a real vulnerability and hears nothing for two weeks. The reporter assumes the issue was ignored, escalates externally, and stops reporting internally. The fix is a documented acknowledgement window (typically twenty-four to seventy-two business hours) that runs on every channel, an automated or named-actor acknowledgement that the reporter sees with the assigned reference, and a quarterly review of acknowledgement latency by channel so the front door stays trusted.

Internal reports get logged but never bind to an asset or a named owner

The report enters as a finding against a vague target ("the staging environment") with no IP, no hostname, no repository, and no named owner. The finding stalls for two cycles because nobody is on the hook. The fix is the same intake discipline the broader queue uses: every internal-disclosure finding pairs to a real engagement, a named asset, and a named owner of record at the moment the security operator opens the record, with RBAC routing rules that push the new record to the right named person.

Duplicates compound because the channel does not check the existing queue

Two developers report the same misconfigured endpoint a day apart. Both reports open as separate findings. The triager spends an hour reconciling. Three months later an automated scan flags the same issue and it opens a third time. The fix is the same dedup-at-the-door discipline the broader intake runs: each internal-disclosure intake checks against the open catalogue for the same asset and the same finding template before opening a new record, and the activity log captures the merge decision.

Severity arrives as the reporter wrote it and never gets calibrated

An engineer marks their report as critical because the affected service is critical. A customer-success forwarded report comes in as low because the customer ticket was logged that way. Severity drifts across the queue and the prioritisation view becomes unsortable. The fix is severity normalisation at intake: the reporter-supplied severity is recorded as the source severity, the workspace severity policy applies the normalised severity against the calibration rule, and any override carries a named reason on the record.

Out-of-scope reports get silently absorbed or silently dropped

A reporter raises an issue against a service that is not in scope for the security programme this quarter (a regional acquisition, a sunset product, a vendor-managed service). The report either lands on the queue and confuses the operating model or never lands at all. The fix is the explicit out-of-scope decision path: every internal-disclosure intake passes a scope check, in-scope reports land on the queue normally, out-of-scope reports land in an out-of-scope queue with a named decision owner who chooses one of three explicit paths (accept by opening a new engagement, defer with a documented rationale, close with a named reason).

Activity log starts at the first triage note rather than at the report

The first event captured on the finding is the triage decision the security analyst recorded three days after the report. The chain of custody from report to triage is missing; the auditor reads the finding without knowing how it got onto the queue, who reported it, or which channel it came in through. The fix is stamping the activity log at intake with the source channel, the original reporter or reporter reference where anonymity protections apply, the source severity, the normalised severity, the asset binding, and the dedup decision, so the chronology is continuous from the first record through remediation, retest, and audit.

Six fields every internal-disclosure intake record has to capture

A defensible internal-disclosure intake is six concrete fields on the finding record, not a free-text title and an inferred severity. The fields make the next triage cycle, the next remediation owner, the next reporter follow-up, and the next audit reconstructable from the record rather than from an email thread the operator who took the report no longer has access to.

Source channel and capture metadata

The named internal channel the report arrived through (security inbox, developer escalation, customer-success forwarded report, internal red team, bug bounty triage handoff, awareness exercise, compliance escalation, anonymous channel), the capture timestamp, the original source reference (email message ID, chat thread permalink, pull request URL, customer ticket reference, internal engagement ID, bounty case ID), and the source severity as recorded before any normalisation. The channel attribution survives into remediation and audit so the chronology is reconstructable rather than rebuilt from memory.

Reporter attribution and acknowledgement policy

The named internal reporter where the channel governance permits identification, or the reporter reference where anonymity protections apply (anonymous-channel ID, customer-handle pseudonym from the bug bounty platform). The acknowledgement policy that applies to the channel (the window, the medium, the named acknowledger), and the timestamp of the acknowledgement that the reporter received. The acknowledgement record is part of the finding rather than a separate email so the audit reads the closed loop on the front door.

Asset binding and ownership at the door

The engagement reference, the target asset (hostname, IP, repository, application service, mobile app, internal tool, business process where the finding is process-shaped rather than asset-shaped), and the named owner of record under the workspace RBAC. The owner of record is the person on the hook for the finding through remediation; the engagement reference is the planning context the finding sits inside. Both are captured at intake so the finding does not stall waiting for a routing decision.

Severity normalisation against the workspace policy

The reporter-supplied severity where one was given, the normalised severity that the workspace operates against, the CVSS 3.1 vector and base score where the security operator can construct one at intake or where the source supplied a vector, and the named reason for any override of the auto-calculated severity. The normalisation policy is a workspace decision; the override reason makes the decision auditable for the next reader.

Evidence body and provenance

The evidence the next reader needs to triage and remediate: the original report body, attached screenshots, the reproduction steps where the reporter supplied them, the affected URL or endpoint, the affected repository and commit SHA for code-side reports, the customer ticket excerpt for forwarded reports, and any redacted detail where anonymity policy requires redaction. Document management holds the original artefacts as versioned attachments cited by the finding rather than re-authored on the record.

Dedup decision and exception match

The result of the dedup check against the open catalogue (new record, merged into existing finding ID, suppressed against an active workspace suppression), the result of the exception match against the workspace exception register (no match, matches accepted risk reference, matches deferral reference, matches false-positive suppression), and the named actor and timestamp for each decision. The intake decisions are queryable so the next operator does not re-litigate them.

Eight queues the workflow runs in parallel during the operating week

Live internal-disclosure intake runs eight queues concurrently. Each queue has a named owner, a documented cadence, and an escalation rule so acknowledgement latency, asset binding, severity normalisation, dedup decisions, and exception matches do not silently fall behind between morning standups.

Unacknowledged-report queue with each internal-disclosure intake captured in the last twenty-four hours whose acknowledgement has not been sent. The view the on-call security operator reads against the documented acknowledgement window.
Unbound-intake queue with each finding awaiting an asset binding or an owner-of-record assignment. The view the intake operator reads to close out routing within the workspace policy.
Channel-health queue with each declared channel against its expected capture cadence and a flag where a channel has gone quiet beyond the documented tolerance. The view that catches a security inbox alias that stopped routing or an awareness programme that stopped forwarding.
Reporter-feedback-pending queue with each acknowledged report whose validity decision has not yet been communicated back to the reporter. The view that keeps the front door trusted by closing the loop on every report.
Dedup-decision queue with each intake where the dedup check flagged a likely existing record, the candidate match, and the named resolver. The view that prevents the catalogue from drifting into parallel records for the same internally-reported issue.
Exception-match queue with each intake that matches an active acceptance, deferral, or suppression, the existing reference, and the inherited expiry. The view that confirms previously-decided cases are not re-litigated on the back of a new internal report.
Out-of-scope queue with each report that landed outside the documented programme scope, the named decision owner, and the acceptance, deferral, or rejection rationale. The view that keeps scope-creep auditable and avoids silently dropped reports.
Anonymous-channel queue with each anonymous report under the governance policy that applies to the channel, the named non-reporter contact for follow-up, and the redaction state of the supporting evidence. The view that runs the operational record without breaching the anonymity protections the originating channel guarantees.

How internal vulnerability disclosure intake runs in SecPortal

The workflow rides on the feature surfaces the security programme already uses. Each channel pushes a manual finding entry against the engagement record, findings management normalises the severity and binds the asset, team management routes the owner of record under RBAC, the activity log captures every intake decision, and notifications push the new record to the named recipient. No bespoke integration is required for the workflow itself; the platform capabilities below are enough.

Findings management as the record

Findings management holds the canonical record for every internal report, with the 300+ remediation templates for manual entry, auto-calculated CVSS 3.1 against any supplied vector, the workspace severity policy, and the activity log of every change.

Engagements as the planning context

Engagement management holds the scope every internal-disclosure finding binds to, so the report attaches to the relevant application or service engagement rather than to a freeform list.

RBAC for routing the named owner

Team management role-based access control assigns the named owner of record at intake and grants the access scope the owner needs to triage and remediate the finding, with owner, admin, member, viewer, and billing roles available.

Document management for evidence

Document management holds the original report bodies, attached screenshots, reproduction steps, and any redacted artefacts where anonymity policy requires redaction, as versioned attachments the finding cites rather than duplicates.

Notifications to the named owner

Notifications and alerts push the new intake record to the named owner of record so the routing decision lands in front of the right person rather than in nobody-noticed inbox limbo, and surface acknowledgement-pending and reporter-feedback-pending queues to the on-call operator.

Activity log for chain of custody

Activity log with CSV export captures the source channel, the actor, the source severity, the normalised severity, the dedup decision, the exception match, and the acknowledgement timestamp at intake so the audit reads the chronology rather than reconstructing it.

Finding overrides for the exception register

Finding overrides holds the documented acceptance, deferral, and false-positive suppression decisions the intake checks against, so a finding that matches an active override inherits the existing reference rather than opening as a duplicate the team has to dismiss.

MFA on the workspace front door

MFA enforcement with TOTP applies to every operator who takes an internal-disclosure intake, so the audit reads that the named acknowledger and the named intake operator authenticated with a second factor before opening the record.

Compliance tracking

Compliance tracking maps each intake to ISO 27001 Annex A 6.8, SOC 2 CC2.3 and CC7.4, NIST SP 800-53 IR-6 and IR-8, NIST CSF 2.0 GV.RR, and PCI DSS 12.10 so the audit chain reads continuous from internal report through closure.

Audit frameworks that read against the workflow

Most enterprise audit and certification cycles ask for evidence that the organisation operates documented channels for reporting security events from inside, that those channels are acknowledged within a documented window, and that the resulting findings join a tracked register with named ownership and a documented response cadence. The workflow produces the evidence those audits read against.

ISO 27001:2022

Annex A 6.8 (reporting information security events) reads against the internal-disclosure intake workflow as the documented mechanism employees, contractors, and named third parties use to report security events to the organisation through approved channels. Annex A 5.24 (information security incident management planning and preparation) reads against the documented channel register and the acknowledgement policy. Annex A 8.8 (management of technical vulnerabilities) reads against the routing from intake through remediation and the audit trail of every state transition. Clause 9 (performance evaluation) reads against the channel-health queue to confirm internal reporting channels are operating as planned.

SOC 2 Trust Services Criteria

CC2.3 (communicating information) reads against the documented internal-disclosure channels and the acknowledgement policy as the controls that surface security-relevant information from internal sources to the security function. CC4.1 (monitoring activities) reads against the routing from intake into the tracked register. CC7.1 (system operations and monitoring) reads against the activity log of every intake. CC7.3 (anomaly response) and CC7.4 (security incident response) read against the named-owner routing and the SLA on each report.

NIST SP 800-53 Rev. 5

IR-6 (incident reporting) reads against the documented internal-disclosure channels as the mechanism that surfaces incidents to the organisation. IR-8 (incident response plan) reads against the channel register, the acknowledgement policy, and the routing matrix. RA-5 (vulnerability monitoring and scanning) reads against the intake from internal sources as a non-scanner channel that contributes to the vulnerability picture. SI-4 (system monitoring) and SI-5 (security alerts, advisories, and directives) read against the internal-disclosure channel as one input alongside scanner output and external advisories.

NIST CSF 2.0

GV.RR (roles, responsibilities, and authorities) reads against the named on-call security operator role, the acknowledgement responsibility, and the named-owner routing. ID.IM (improvement) reads against the channel-health queue and the acknowledgement-latency review. DE.AE (anomalies and events) reads against the intake from internal channels as one detection path. RS.CO (incident response communications) reads against the reporter-feedback-pending queue as the closed-loop discipline that maintains channel trust.

PCI DSS v4.0

Requirement 12.10 (incident response plan documented and tested) reads against the documented channel register and the routing from intake into the tracked register. Requirement 12.5.2.1 (PCI DSS scope confirmation) reads against the scope check at intake that decides which reports land on the programme queue. Requirement 6.3.1 (security vulnerabilities are identified and managed) reads against the routing from internal-disclosure intake into the vulnerability remediation workflow.

CIS Controls v8.1

Control 17 (incident response management) reads against the internal-disclosure intake as the structured channel that turns internal reports into tracked work. Safeguard 17.3 (establish an incident response process) and 17.4 (establish a contact information for reporting incidents) read against the documented channel register and the on-call rota. Control 14 (security awareness and skills training) reads against the channel that turns awareness-exercise output into remediation work rather than only into training metrics.

Where the workflow fits in the wider operating model

Internal-disclosure intake is one of several intake disciplines that feed the broader vulnerability management queue. The references below trace how the structured intake record carries into the rest of the programme. Each adjacent workflow reads against the same finding record rather than rebuilding a parallel register.

Broader finding intake

The vulnerability finding intake workflow is the broader queue that internal-disclosure findings join, with the same dedup, exception register, and named-owner routing applied across every source.

External disclosure programme

The external VDP workflow is the outward-facing counterpart that publishes the public rules under ISO/IEC 29147 and 30111; internal-disclosure intake is the inward-facing counterpart for reports that originate inside.

Product-vendor PSIRT

The PSIRT workflow is the product-vendor discipline for issues against shipped products; it pairs with this workflow at organisations that ship products and also operate an internal estate.

Scanner result triage

The scanner result triage workflow is the downstream discipline that validates the intake, reproduces evidence, calibrates severity for the environment, and promotes confirmed findings into the remediation queue.

Asset ownership mapping

The asset ownership mapping workflow provides the named owner of record the intake routing rule reads, so a finding does not stall waiting for an owner-discovery process the morning standup runs by hand.

Routing and ownership

The security finding ownership and routing workflow converts the intake record into a routed work item with the primary owner, watchers, and the named approver where the finding requires sign-off.

Exception management

The acceptance and exception management workflow is the register the intake checks against so previously accepted risks do not produce new tickets the team has to dismiss.

Prioritisation

The prioritisation workflow reads the normalised intake queue with the asset criticality multiplier to decide what the team works first rather than letting reporter sequence drive the schedule.

Fix verification

The security finding fix verification workflow is the closing discipline that runs against the same finding record at the end of the cycle so the intake provenance and the proof-of-fix evidence travel together on one continuous record.

Audiences that operate against this workflow

The workflow serves the operators and leaders responsible for the front door of internal security reporting. Each audience reads the workflow with a slightly different lens.

Internal security teams

Internal security teams read the workflow as the operational discipline that turns the shared inbox into a queryable queue defensible across the channel mix.

AppSec teams

AppSec teams read the workflow as the channel that pulls developer escalations, internal review findings, and pull request security comments into a single application-anchored record.

Product security teams

Product security teams read the workflow as the front door for internal reports against the shipped product estate, paired with PSIRT for externally-coordinated cases.

Vulnerability management teams

Vulnerability management teams read the workflow as one of the upstream sources of the queue they triage, prioritise, and burn down across the operating week.

GRC and compliance teams

GRC and compliance teams read the workflow as the upstream evidence chain ISO 27001 Annex A 6.8, SOC 2 CC2.3 and CC7.4, NIST SP 800-53 IR-6, and PCI DSS 12.10 audits cite for internal incident and vulnerability reporting.

CISOs and security leaders

CISOs and security leaders read the workflow as the leading indicator of whether the organisation has a trusted internal reporting culture or a shared inbox the rota reads when it can.

Honest scope

The workflow runs on the workspace record itself rather than as a channel orchestration layer. SecPortal does not act as the inbound mail server for the security@ inbox, does not parse incoming Slack or Teams messages, does not run automated triage classification against report bodies, does not enforce the acknowledgement window through bot automation, and does not ship native Jira, ServiceNow, Slack, Teams, PagerDuty, SIEM, or SOAR push connectors. The on-call security operator who reads each channel pastes the inbound content into a manual finding entry against the relevant engagement; the platform holds the structured record, the routing, the activity log, and the audit trail from that point forward.

For anonymous internal reporting channels the workflow honours the originating governance: the acknowledgement and reporter-feedback path runs through the originating channel rather than through the workspace so the anonymity protections the channel guarantees are not broken at the operational record. The workspace holds the non-identifying intake, the named non-reporter contact for follow-up, and the redaction state of supporting evidence.

Frequently asked questions

What is the internal vulnerability disclosure intake workflow?

The internal vulnerability disclosure intake workflow is the structured front-door process the internal security team uses to receive vulnerability reports from inside the organisation: from employees, contractors, internal teams, internal red teams, internal-customer escalations forwarded by customer success or support, bug bounty triage handoffs that arrive internally for remediation, awareness exercise outputs, compliance and audit escalations, and anonymous internal channels. Each report lands on an engagement record with a named source channel, a captured reporter (or reporter reference where anonymity policy applies), an acknowledgement to the reporter, an asset binding, a named owner of record, a normalised severity, a dedup check, and an activity log entry that survives into remediation and audit.

How is this different from a vulnerability disclosure program (VDP)?

A vulnerability disclosure program is the externally-facing programme that publishes the rules under which researchers, customers, and the wider public can report vulnerabilities to the organisation, typically aligned to ISO/IEC 29147 and 30111 and (in the United States federal context) CISA BOD 20-01. Internal vulnerability disclosure intake is the inward-facing counterpart: the channels and discipline the organisation uses for reports that originate inside the organisation, including reports that land from external programmes after they have been triaged externally and are being handed in for remediation. The two operate together: the VDP defines the external relationship; the internal intake holds the operational record. The same finding can move from the VDP into the internal intake after acceptance and remain linked.

How is this different from PSIRT (product security incident response)?

PSIRT (product security incident response) is the discipline a product vendor runs to handle every vulnerability that lands against the products the vendor ships, ending in coordinated public disclosure with a CVE identifier and a security advisory. PSIRT is product-shaped, vendor-facing, and ends in public disclosure to downstream consumers. Internal vulnerability disclosure intake is broader and infrastructure-shaped: it covers every internally-reported security issue across applications, infrastructure, business processes, internal tools, and vendor-managed services that the organisation operates rather than only the products it ships. A vendor organisation runs both: PSIRT for the products it ships, internal-disclosure intake for the rest of the estate.

How is this different from the broader vulnerability finding intake workflow?

The broader vulnerability finding intake workflow covers every inbound finding from every source: scanner output, code scanning, bulk imports of prior pentest reports, third-party penetration test reports, manual pentest entries, external VDP submissions, and internal escalations. Internal vulnerability disclosure intake is the subset that focuses on the human-reported internal channels: the security inbox, developer escalations, customer-success forwarded reports, internal red team output, awareness exercise findings, compliance escalations, and anonymous internal channels. The two run together: the broader intake is the queue; the internal-disclosure intake is the discipline that holds the specific channels where people inside the organisation surface issues to the security function.

What acknowledgement policy should the channel run on?

A documented acknowledgement window is the discipline that keeps the front door trusted. The defensible default is twenty-four to seventy-two business hours from receipt to acknowledgement on the named security inbox, faster on the developer-escalation channel where the in-the-moment context is the value, and adjusted on the anonymous channel to honour the originating governance. The acknowledgement records the assigned reference, the named acknowledger, and the timestamp on the finding record so the audit reads the closed loop rather than a recipient confirmation that lives only in email. Reviewing acknowledgement latency by channel on a quarterly cadence catches a drifting front door before reporters lose confidence and stop reporting.

How does the workflow handle anonymous internal reporting channels?

The workflow honours the anonymity protections the originating channel guarantees. Reports arriving through the corporate ethics line, the whistleblower channel, or the internal speak-up portal land on the finding record without identifying the reporter beyond what the anonymous-channel governance permits. The originating channel reference, the reporter-anonymity policy reference, and the named non-reporter contact for follow-up stay attached to the finding so the chronology is auditable without exposing the protected identity. The acknowledgement and reporter-feedback path runs through the originating channel rather than through the workspace so the anonymity guarantees are not broken at the operational record.

How does the workflow handle out-of-scope reports?

Each internal-disclosure intake passes a scope check at the door against the documented programme scope. In-scope reports land on the queue normally. Out-of-scope reports (a regional acquisition that has not yet been onboarded, a sunset product that is no longer in the support window, a vendor-managed service the contract assigns elsewhere) land in an out-of-scope queue with a named decision owner who chooses one of three explicit paths: accept the finding by opening a new engagement that covers the previously out-of-scope work, defer the finding with a documented rationale and a re-evaluation date, or close the finding with a named reason that the reporter sees. The explicit path means the queue does not silently absorb undirected work and does not silently drop reports the programme should have decided about.

How does the workflow handle severity at intake?

The reporter-supplied severity (where one was given) is recorded as the source severity on the finding. The workspace severity policy applies the normalised severity against the calibration rule, recomputed against the affected asset criticality and the deployed exposure. Where the security operator can construct a CVSS 3.1 vector at intake against the reproduction the reporter supplied, the vector lands on the finding and the base score auto-calculates. Where the source severity and the normalised severity diverge, the override carries a named reason on the record so the next reader reads the calibration rather than re-deriving it.

How does the workflow keep duplicates from compounding?

Each internal-disclosure intake checks against the open catalogue for the same asset and the same finding template before opening a new record. Where the dedup check flags a likely existing record, the intake operator decides whether the new report is a duplicate (merge into the existing finding ID with the new reporter attribution added to the chronology), a variant (open a related record with the cross-reference set), or genuinely separate (open a new record with the dedup decision logged). The decision lands on the activity log so the audit chronology reads as one finding rather than three parallel records for the same internally-reported issue.

How does the workflow check against the existing exception register?

Each new finding checks against the workspace exception register (accepted risks with active expiries, deferrals against scheduled remediation windows, workspace-wide false-positive suppressions for known patterns) before it lands on the open queue. A finding that matches an active exception inherits the existing reference and the existing expiry rather than opening as a new record the team has to dismiss. The exception match is recorded on the activity log so the audit reads that the programme already decided this case and the reporter sees that the issue is already on a documented track rather than being ignored. Findings that do not match any active exception land on the open queue with the named owner.

Does the workflow require integrations with engineering ticketing systems or chat platforms?

No. The workflow operates on the workspace record itself. Findings land on the engagement, the activity log captures the chronology, notifications and alerts surface the new records to the named owner of record, and the audit trail lives on the platform. Teams that route findings to engineering ticketing or to a chat channel for visibility run those handoffs as separate disciplines downstream of intake. SecPortal does not ship native Jira, ServiceNow, Slack, or Teams push connectors, and the workflow does not depend on them; the on-call security operator who reads the channels pastes the inbound report into a manual finding entry against the relevant engagement.

How does the workflow close the loop with the reporter?

The reporter-feedback-pending queue is the operational discipline that keeps the front door trusted. After the triage decision (confirmed vulnerability, working as designed, duplicate of an existing finding, accepted as a documented risk, or out of scope with a named reason), the reporter receives a communication that names the decision and the assigned reference. For internally-identified reporters this runs as a notification or an email; for anonymous-channel reporters this runs back through the originating channel under its governance. Closing the loop on every report is the difference between a front door reporters trust and a front door that silently drops half the input.

How does the workflow support reporter recognition and internal credit?

Where the channel governance permits identification, the named reporter is captured on the finding record and surfaces in the activity log. Programmes that operate an internal hall-of-fame or recognition scheme can read the reporter field across closed findings to produce the recognition list on a quarterly or annual cadence. The recognition scheme runs outside the platform; the data the scheme reads against is the same finding record the audit reads against. For external bug bounty cases that arrive internally for remediation, the credit handling remains with the bug bounty platform; the internal record captures the external attribution so the two stay coordinated.

How it works in SecPortal

A streamlined workflow from start to finish.

Declare every internal channel and its governance

A defensible intake workflow starts with a register of accepted internal channels: the named security inbox (security@, secalerts@, security-reports@), the developer-escalation channel in engineering chat or pull request review, the customer-success forwarded-report path, the internal red team and in-house pentest engagement, the bug bounty triage handoff for externally-validated reports being worked internally, the awareness exercise and tabletop output, the compliance and legal cross-function escalation, and the corporate anonymous reporting channel (ethics line, whistleblower portal, speak-up portal). Each channel declares its acknowledgement window, its on-call ownership, its anonymity governance where one applies, and its in-scope and out-of-scope rules. Channels outside the register do not land on the queue without an explicit acceptance decision.

Acknowledge every report within the documented window

The acknowledgement is the closed loop that keeps the front door trusted. Each inbound report receives a named-actor acknowledgement with the assigned reference, the receiving operator name, and the timestamp, captured on the finding record rather than living only in email. The defensible default is twenty-four to seventy-two business hours on the security inbox, faster on the developer-escalation channel, and adjusted on the anonymous channel to honour the originating governance. Acknowledgement latency is reviewed quarterly by channel so a drifting front door surfaces before reporters lose confidence and stop reporting.

Bind every report to a real engagement, asset, and named owner

A report without an asset binding is a ticket waiting to be lost; a report without an owner of record is a ticket waiting to be dropped. At intake, every finding pairs to the engagement (the application or service or business process the report concerns), the target asset (hostname, IP, repository, application service, internal tool, business process where the finding is process-shaped), and the named owner of record under the workspace RBAC. The owner of record is captured on the finding itself, not in a forwarded email. Routing rules at intake read the asset tier and the source channel so security-critical reports reach the named on-call rather than the morning standup.

Normalise severity against the workspace policy

Reporters speak different severity languages. A developer reports a finding as critical because the affected service is critical; a customer-success forwarded report comes in as low because the customer ticket was logged that way; an anonymous reporter often supplies no severity at all. The reporter-supplied severity is recorded as the source severity on the finding. The workspace severity policy applies the normalised severity against the calibration rule, recomputed against the affected asset criticality and the deployed exposure. Where the security operator can construct a CVSS 3.1 vector at intake against the reproduction the reporter supplied, the vector lands on the finding and the base score auto-calculates. Any override of the auto-calculated severity carries a named reason on the record.

Deduplicate at the door, not three weeks later

Each internal-disclosure intake checks against the open catalogue for the same asset and the same finding template before opening a new record. Where the dedup check flags a likely existing record, the intake operator decides whether the new report is a duplicate (merge into the existing finding with the new reporter attribution added to the chronology), a variant (open a related record with the cross-reference set), or genuinely separate (open a new record with the dedup decision logged). The decision lands on the activity log so the audit chronology reads as one finding rather than three parallel records for the same internally-reported issue.

Check the exception register before opening a new ticket

Handle out-of-scope reports through an explicit decision path

Each intake passes a scope check at the door against the documented programme scope. In-scope reports land on the queue normally. Out-of-scope reports (a regional acquisition that has not yet been onboarded, a sunset product no longer in the support window, a vendor-managed service the contract assigns elsewhere) land in an out-of-scope queue with a named decision owner who chooses one of three explicit paths: accept the finding by opening a new engagement that covers the previously out-of-scope work, defer the finding with a documented rationale and a re-evaluation date, or close the finding with a named reason that the reporter sees. The explicit path means the queue does not silently absorb undirected work and does not silently drop reports the programme should have decided about.

Close the loop with the reporter and stamp the activity log

After the triage decision (confirmed vulnerability, working as designed, duplicate of an existing finding, accepted as a documented risk, or out of scope with a named reason), the reporter receives a communication that names the decision and the assigned reference. For internally-identified reporters this runs as a notification or an email; for anonymous-channel reporters this runs back through the originating channel under its governance. The activity log captures the channel, the actor, the source severity, the normalised severity, the asset binding, the dedup decision, the exception match, the acknowledgement timestamp, and the reporter-feedback timestamp so the audit reads the chronology rather than reconstructing it.

Features that power this workflow

Vulnerability management software that tracks every finding

Orchestrate every security engagement from start to finish

Collaborate across your entire team

Document management for every security engagement

Every action recorded across the workspace

Notifications and alerts for the people who carry the work

Finding overrides that survive every scan cycle

Multi-factor authentication on every workspace

Compliance tracking without a full GRC platform

AI-powered reports in seconds, not days

Global search across every engagement, finding, and client

Run internal vulnerability disclosure intake as a structured workflow

Documented channels, acknowledgement window, named owners at the door, severity normalisation, dedup at intake, exception register check, and an audit trail that survives into remediation. Start free.