What is a vulnerability intelligence operating model?

A vulnerability intelligence operating model is the written discipline that turns multiple external intelligence sources (CISA KEV, EPSS, EUVD, NVD, vendor advisories, exploit databases, social signals, threat feeds) into one defensible prioritisation feed that drives the internal vulnerability management workspace. It is not a single feed or a single score. It is a set of named sources, a documented enrichment workflow, a written decision rule that combines exploitation evidence with predicted exploitability and internal exposure, a cadence for refresh, named owners for each source, and an audit trail that explains why a finding was prioritised the way it was. The model exists so leadership can answer the question, not why a vulnerability is critical, but why this enterprise treated this confirmed weakness on this asset as a tier-zero remediation decision.

Why do enterprises need a vulnerability intelligence operating model?

Most enterprises subscribe to four or more vulnerability intelligence sources without a written rule for how the sources combine. CISA KEV says one set of vulnerabilities is actively exploited. EPSS says another distribution of CVEs has the highest predicted thirty-day exploitation probability. The NVD CVSS base score says a third set is critical. The vendor advisory for a deployed product names a fourth set as the highest patch priority. Internal authenticated scans say a fifth set is present on the live estate. Without an operating model the four sources produce four different prioritisation answers and the audit committee asks which one is the enterprise position. The operating model converts the four sources from four parallel signals into one decision rule that produces one workspace-ready prioritisation feed every cadence cycle.

Which intelligence sources should the operating model use?

A defensible operating model uses six source families. Exploitation evidence (CISA Known Exploited Vulnerabilities catalogue, ransomware-named KEV entries, CERT advisories on active exploitation, exploit database listings). Exploitation prediction (FIRST EPSS daily score with thirty-day probability and percentile). Identifier and metadata authority (NVD CVE entries, CWE references, CVSS 3.1 and 4.0 vectors and scores, CPE mapping). Regional or sector identifiers (EUVD, JVN, CN-VD where the enterprise has operations subject to those jurisdictions). Vendor advisories (vendor security pages for every product class on the inventory, including operating systems, runtimes, container base images, libraries, hardware, and cloud platform services). Threat reporting (vendor and ISAC reports on active campaigns, attacker TTPs from MITRE ATT&CK, and validated exploit code release). Sources outside the six families are optional and earn their place by adding a decision the existing six families cannot make.

How is the operating model integrated with the vulnerability management workspace?

Every confirmed finding on the workspace carries the enrichment fields the decision rule reads. The CVE identifier, the CVSS 3.1 and 4.0 vectors, the KEV listing flag with the recorded due date, the EPSS score with timestamp, the asset criticality, the deployed exposure, and the vendor advisory reference live on the same finding record where the severity, owner, and SLA are set. The enrichment happens at the intake stage so the operating cadence reads against the enriched record. Findings without enrichment fail the data quality cycle and land on the hygiene queue rather than the live tier queue. The same record carries the activity log so the audit lookback reads the rationale chain that turned the source signal into the tier assignment.

What is the refresh cadence for vulnerability intelligence?

The cadence has four layers. The intra-day cadence covers the CISA KEV additions and the high-impact vendor advisories on a watch list. New KEV entries that match a CPE present on the inventory trigger a same-day triage cycle and an SLA clock start. The daily cadence covers the EPSS feed refresh and re-scores the open backlog against the new percentile threshold. The weekly cadence reviews the additions and removals across all six source families, refreshes the vendor advisory watch list, and reads the calibration drift between the predicted scores and the active exploitation reports. The quarterly cadence reads the decision rule against the operating data and adjusts the thresholds if the rule produced false positives or missed exploitation events the post hoc evidence shows the rule should have caught.

How does the operating model handle vendor advisories without a public CVE?

Vendor advisories without a CVE arrive as named issues from the vendor security page. The intake workflow captures the advisory identifier, the affected product version, the patch reference, the named severity from the vendor, and the disclosure date. The advisory lands on the workspace findings view as a confirmed finding with the vendor identifier in the source field, the affected asset binding from the inventory, and a placeholder CVE field updated when the public identifier publishes. The tier assignment runs against the vendor severity until the public CVE arrives with EPSS and CVSS metadata, at which point the standard decision rule overrides the placeholder. The arrangement keeps vendor-reported issues on the operating cadence rather than parked until the public CVE catches up.

How does the model treat exceptions and compensating controls?

A tier-zero or tier-one finding without a remediation path within the SLA window goes through the exception workflow rather than aging silently. The exception captures the named compensating control, the residual risk acceptor, the expiry date, the renewal trigger, and the planned remediation path. The compensating control is recorded in language the audit lookback can read: which control reduces the exploitability of this CVE on this asset, how the control is verified, and when the control expires. The exception register lives on the workspace as a structured queue with the renewal cadence enforced through notifications. Open exceptions on KEV-listed findings receive an extra review at the monthly programme review because the audit committee reads them on first inspection.

How does SecPortal support the vulnerability intelligence operating model?

SecPortal gives the operating model a single workspace where findings management, bulk finding import, finding overrides, retesting workflows, finding comments and collaboration, the activity log with CSV export, AI report generation, compliance tracking across framework templates, continuous monitoring with scheduled scans, team management with RBAC, MFA, and notifications run against one record. The enriched finding carries CVSS, CWE, source identifier, asset binding, and the override history. The activity log captures every state change with named participant and timestamp so the audit lookback reads the rationale chain. The platform does not author the policy library, set the EPSS threshold, or sign the exception; it does keep the operating cadence, the enrichment workflow, the tier queues, and the audit evidence on one auditable record rather than across spreadsheets, ticket trackers, and intelligence portals.

← Back to Blog

Enterprise23 May 202621 min read

Vulnerability Intelligence Operating Model: Turning KEV, EPSS, EUVD, and Vendor Feeds into One Defensible Prioritisation Feed

Most enterprises subscribe to four or more vulnerability intelligence sources without a written rule for how the sources combine. The CISA Known Exploited Vulnerabilities catalogue names one set of CVEs as actively exploited. The FIRST EPSS feed predicts a different distribution as the highest near-term exploitation risk. The NVD CVSS base score scores a third set as critical. The vendor advisory page on a deployed product names a fourth set as the highest patch priority. The authenticated internal scan says a fifth set is present on the live estate. Five sources produce five different prioritisation answers, and the audit committee asks which one is the enterprise position. This guide is for CISOs, AppSec leads, vulnerability management owners, security engineering, and GRC teams who need to turn those five answers into one defensible operating model. It walks through the source families, the enrichment workflow, the written decision rule, the cadence, the exception path, the framework crosswalk, and the workspace pattern that converts the intelligence into an operating discipline rather than a slide pack.

What a Vulnerability Intelligence Operating Model Is, and What It Is Not

The vulnerability intelligence operating model is the written discipline that turns multiple external intelligence sources into one defensible prioritisation feed that drives the internal vulnerability management workspace. It is not a single feed; the enterprise is not waiting for one vendor to publish the perfect prioritisation rating. It is not a single score; CVSS, EPSS, and KEV measure different things and combining them by summing scores produces nonsense. It is not a tool; the tool layer is downstream of the operating decision. It is the set of named sources, the documented enrichment workflow, the written decision rule that combines the sources, the cadence for refresh, the named owners for each source, and the audit trail that explains why a finding was prioritised the way it was.

The operating model exists so leadership can answer two questions with the same record. The first question is internal: which open finding should the engineering team pick up next. The second question is external: why did the enterprise treat this confirmed weakness on this asset as a tier-zero remediation decision. A programme that runs without a written operating model can usually answer the first question informally and almost never answer the second question defensibly. The audit, the regulator, and the board reader want the second answer in writing.

Mature programmes converge on similar operating models even when they start from different tooling. The components are the same across the enterprise software stack, the financial services regulator brief, and the federal civilian agency BOD 22-01 alignment: a source list, an enrichment workflow, a decision rule, a cadence, an exception path, and an audit trail. The rest of this guide is each component in turn.

The Six Intelligence Source Families

A defensible operating model uses six source families. The families are not interchangeable. Each family answers a different question, and the decision rule combines the answers rather than treating them as parallel scores.

1. Exploitation evidence

The CISA Known Exploited Vulnerabilities catalogue is the anchor source for confirmed, observed, in-the-wild exploitation. Ransomware-named KEV entries and CERT advisories on active exploitation extend the picture. Exploit database listings (such as public exploit code release on widely-tracked sites) confirm that working exploitation primitives are available. The family answers the question, is this vulnerability being exploited right now. See the practical guide on the CISA KEV catalogue for the operational detail.

2. Exploitation prediction

The FIRST EPSS daily feed publishes a thirty-day predicted exploitation probability and a percentile rank per CVE. The family answers the question, how likely is this vulnerability to be exploited in the next thirty days. EPSS is calibrated against observed exploitation and updates as the picture changes. See the practical guide on the EPSS score and how to set a defensible threshold for tier assignment.

3. Identifier and metadata authority

The NVD CVE entries, the CWE references, the CVSS 3.1 and 4.0 vectors and scores, and the CPE mapping form the identifier substrate the other sources reference. The family answers the question, what is the vulnerability, where does it live in the weakness taxonomy, and how severe is the underlying issue independent of operational context. See the practical guides on the CVE numbering authority programme and the Common Weakness Enumeration.

4. Regional and sector identifiers

The European Union Vulnerability Database (EUVD), the JPCERT/CC JVN catalogue, the China CN-VD identifier registry, and sector-specific registries (ICS-CERT, FS-ISAC bulletins, H-ISAC advisories) produce identifiers and advisories that do not always reach the NVD feed in time. The family matters for enterprises with regulatory exposure in the relevant jurisdiction or sector. The intake workflow keeps the regional identifier alongside the CVE so the audit lookback reads the same record across jurisdictions.

5. Vendor advisories

Vendor security pages publish patches, severity ratings, and disclosure narratives for every product class on the inventory: operating systems, runtimes, container base images, libraries, hardware, and cloud platform services. The vendor severity reflects the vendor knowledge of the affected code path and tends to lead the public CVE timeline. The family answers the question, what does the vendor say about exploitability and patch priority for the version the enterprise runs.

6. Threat reporting and exploitation context

Vendor and ISAC reports on active campaigns, attacker TTP cataloguing through MITRE ATT&CK references, validated exploit code release tracking, and threat actor attribution narratives provide the operational context for the prioritisation decision. The family answers the question, who is using this vulnerability and how, which the first five families do not address directly.

Sources outside the six families are optional and earn their place by adding a decision the existing six families cannot make. Dark-web exploit market chatter, attacker forum mentions, and proprietary threat intelligence feeds belong to family six and the intake workflow evaluates each feed against whether it changes a tier assignment that the other five families would already produce. Feeds that consistently change the picture stay; feeds that produce noise without changing the rule output go.

The Enrichment Workflow: Landing Source Values on the Finding Record

The operating model fails if the source signals live in five different portals while the workspace finding record carries only the scanner output. The enrichment workflow is the piece that lands the source values on the finding record at intake so the decision rule runs against the data rather than against the documentation. The workflow has six steps that run as a standard intake pipeline for every confirmed finding.

Identifier resolution. The CVE, the vendor advisory identifier, the EUVD reference, and the CWE land on the finding record as structured fields. Findings without an identifier enter the hygiene queue rather than the live tier queue.
CVSS capture. The CVSS 3.1 and CVSS 4.0 vectors and scores land on the finding. Where the score is present but the vector is missing the vector gets reconstructed and the score is recomputed to ensure the metric set matches the published vector.
KEV check. The CISA KEV listing flag, the KEV addition date, the KEV recorded remediation due date, and the ransomware-named indicator land on the finding. KEV findings on the live estate skip the tier evaluation and land at tier zero.
EPSS lookup. The EPSS daily score, the EPSS percentile, and the lookup timestamp land on the finding. The lookup repeats on the daily refresh cadence so the open backlog reflects the live prediction rather than the intake-day snapshot.
Vendor advisory cross-reference. The vendor advisory identifier, the vendor-named severity, the vendor patch reference, and the vendor exploitation note land on the finding when the vendor publishes for the affected product class on the inventory.
Asset and exposure binding. The affected asset reference resolves against the inventory, the asset criticality tier resolves against the policy library, and the deployed exposure (internet-facing, internal, or air-gapped) resolves against the asset metadata. The combined record carries the operational context the decision rule reads against.

The enrichment is deterministic and re-runnable. Findings that arrive without the enrichment fields fail the data quality check and route to the hygiene queue rather than receiving a tier assignment. The operating discipline is that no tier-zero or tier-one finding leaves the queue without the full enrichment record because the audit lookback reads the enrichment as the rationale chain for the prioritisation decision. The same approach feeds the broader security finding data quality workflow so the hygiene cadence and the intelligence enrichment land on the same record discipline.

The Written Decision Rule: Five Tiers, One Order

The decision rule is a written, ordered combination, not a sum. Combining KEV, EPSS, CVSS, and vendor severity by adding scores produces a single number that hides which signal is driving the result. Combining them in an ordered tier model preserves the reasoning chain so the audit and the engineering team both read the same rationale. A defensible default rule has five tiers.

Tier zero: Confirmed exploitation against the estate

Any CVE present on the live estate that appears on the CISA KEV catalogue. The CISA-recorded remediation due date is the deadline; the SLA clock starts on KEV addition rather than on scanner discovery. Tier zero overrides every other source signal and bypasses standard tier evaluation. The same logic applies to vulnerabilities named in a CERT or ISAC active exploitation advisory when the affected CPE is present on the inventory.

Tier one: High predicted exploitation with high severity

Any CVE present on the live estate with EPSS at or above the enterprise-defined threshold (commonly the 95th percentile, with the 97th percentile used by programmes that need a narrower top-tier filter) plus a CVSS 3.1 base of critical or high. Tier one captures the CVEs that are not yet on KEV but are at the top of the prediction distribution. The threshold value is written into the policy library and reviewed quarterly against the rule output.

Tier two: Critical-asset escalation and vendor-named exploitation

Any CVE with a tier-zero or tier-one rating on a critical asset class escalates regardless of source priority, plus any vulnerability with a vendor advisory naming active exploitation outside the KEV catalogue. Critical asset classes are defined in the asset criticality policy; common entries are externally-exposed authentication providers, customer-data systems, regulated payment systems, and the workspace platform itself.

Tier three: Standard high-severity remediation

Remaining critical and high CVSS findings on the estate with an EPSS score above the standard remediation threshold (commonly the 70th to 85th percentile). The standard severity-tier SLA from the vulnerability remediation SLA policy applies.

Tier four: Medium-severity backlog

Medium CVSS findings without exploitation evidence and with EPSS below the standard threshold. Tier four is the backlog tier. It is reviewed monthly and remediated under the standard medium SLA. Programmes that try to operate without a tier-four cohort tend to lose visibility into the medium-severity drift that becomes tomorrow tier-zero.

The thresholds live in the policy library and the engineering work is the enrichment workflow that lands the source values on the finding record at intake so the rule runs against the data. The decision rule itself is one written page. Programmes that try to encode the rule in tribal knowledge across a triage team tend to find that the rule drifts across analysts and audit reads cannot reconstruct the rationale. The written rule, the structured enrichment, and the activity log capturing every tier reassignment land the operating model on a defensible footing. The approach pairs with SSVC stakeholder vulnerability categorisation for programmes that want decision-tree-style refinements within each tier.

The Refresh Cadence: Four Layers

The cadence has four layers. The cadence is the discipline that prevents the enrichment from becoming a snapshot taken on intake day and never refreshed. Source feeds change daily; the operating model has to read against the live feed rather than the historical record.

Intra-day cadence (continuous)

CISA KEV additions and high-impact vendor advisories on the watch list trigger a same-day triage cycle and SLA clock start where the affected CPE is present on the inventory. The cadence target is sub-four-hours between feed update and finding-record tier assignment for tier-zero candidates. The intra-day cadence is the layer that separates programmes that read the KEV catalogue as a policy from programmes that operate against it.

Daily cadence

The EPSS feed refresh runs daily. The open backlog is re-scored against the new EPSS percentile threshold and tier assignments are updated where the score crossed a tier boundary. The daily cadence captures the EPSS drift that elevates a tier-three finding into tier-one without anyone noticing on the weekly review.

Weekly cadence

The weekly review reads additions and removals across all six source families, refreshes the vendor advisory watch list against the deployed inventory, and reads the calibration drift between the predicted scores and the active exploitation reports. The weekly review also lands the named owner for new tier-zero and tier-one entries and clears the hygiene queue from the intake week.

Quarterly cadence

The quarterly review reads the decision rule against the operating data and adjusts the thresholds if the rule produced false positives the team had to override repeatedly, or missed exploitation events that the post hoc evidence shows the rule should have caught. The quarterly review also reads the source list against the operational outcome: feeds that consistently change the picture stay; feeds that produce noise without changing the rule output go.

The four-layer cadence runs against the same workspace record. Programmes that operate the cadence on rebuilt spreadsheets tend to discover at the quarterly review that the intra-day cadence never ran in practice because the workflow could not survive an analyst going on leave. The cadence that runs against the live record survives the analyst rotation, the audit fieldwork week, and the CISO transition.

The Exception Path: When the SLA Cannot Be Met

A tier-zero or tier-one finding without a remediation path within the SLA window goes through the exception workflow rather than aging silently. The exception captures the named compensating control, the residual risk acceptor, the expiry date, the renewal trigger, and the planned remediation path. The compensating control is recorded in language the audit lookback can read.

The exception is a structured record on the workspace, not an email. The renewal cadence is enforced through notifications on the workspace, and the expiry date is a hard date rather than a rolling assumption. Open exceptions on KEV-listed findings receive an extra review at the monthly programme review because the audit committee reads them on first inspection. The exception register sits on the workspace alongside the open backlog so the leadership read reflects the full posture, including the named risk acceptance decisions and their expiry timelines.

The exception path is also where the operating model interfaces with the broader risk function. A named residual risk acceptor is required for every tier-zero exception and the acceptor lands on the record alongside the technical compensating control. The arrangement keeps the structural risk decision visible to the audit lookback and prevents the silent accumulation of unowned exceptions that becomes the next material audit finding.

VEX and Outbound Publishing: Closing the Loop with the Ecosystem

The operating model has an outbound dimension when the enterprise ships software. The Vulnerability Exploitability eXchange (VEX) format lets the enterprise publish a structured statement of whether a CVE present in a shipped component actually affects the product. A VEX statement converts the customer-side noise (the customer SBOM scan reports a critical CVE in a dependency) into a defensible vendor answer (the dependency is present but the vulnerable code path is not reachable in the product configuration).

VEX is not optional for programmes that ship software to enterprise customers; customer vulnerability management teams increasingly require it as the SBOM landscape matures. The operating model integrates VEX by treating the inbound finding (from the product SBOM scan) and the outbound VEX statement as two views of the same record. The same enrichment fields feed the customer-facing statement, and the same audit trail records the reasoning. See the practical guide on VEX (Vulnerability Exploitability eXchange) for the format detail and the publishing workflow that lands the same record on the customer assurance pack.

For enterprises that consume software, the VEX inbound is the mirror operation. A vendor VEX statement on a CVE present in a deployed component lets the enterprise prioritisation feed read the vendor not-affected statement as an authoritative downgrade rather than an inbox attachment. The operating model treats VEX statements from vendors as a source on the enrichment workflow alongside the vendor advisory family.

The Framework Crosswalk: One Record, Many Reads

The operating model produces evidence read by multiple compliance and regulatory frameworks. Programmes that re-assemble evidence per audit pay the assembly cost in audit-week capacity; programmes that operate the model against the record pay the assembly cost once during the crosswalk build and re-use the result for years.

SOC 2 and ISO 27001

SOC 2 CC7.1 system operations, CC7.4 incident response coordination, and CC9.1 risk identification read the operating record. ISO 27001 Annex A 5.7 threat intelligence, 8.8 management of technical vulnerabilities, and 8.16 monitoring activities read the same record from the threat-intelligence angle. The framework crosswalk produces one evidence pack that satisfies both reads. See the ISO 27001 framework page for the control-by-control mapping.

PCI DSS

PCI DSS Requirement 6.3 vulnerability remediation, 11.4 testing, and 12.10 incident response read the operating record for cardholder-data scope. The PCI assessor reads the same intelligence operating model the rest of the audit set reads, with the cardholder-data scope filter applied through the asset criticality policy.

NIST SP 800-53 and NIST CSF 2.0

NIST SP 800-53 RA-3 risk assessment, RA-5 vulnerability monitoring and scanning, SI-2 flaw remediation, and SI-5 security alerts read the operating record on the 800-53 side. NIST CSF 2.0 ID.RA risk assessment, DE.CM continuous monitoring, and RS.MI response mitigation read the same record on the CSF side. The crosswalk produces one evidence pack that satisfies both reads.

CISA BOD 22-01 and CIS Controls

CISA Binding Operational Directive 22-01 reads the KEV-listed findings on the operating record with the recorded due date enforced through the SLA breach escalation chain. CIS Controls v8 Control 7 (continuous vulnerability management) reads the asset inventory, vulnerability identification, prioritisation, remediation, and verification flow end to end. The same record answers both reads.

The crosswalk is read once by the audit and evidence role and reused across audits. Programmes operating multiple regulatory regimes (FedRAMP, DORA, NIS2, HIPAA, GDPR) layer their reads on the same record rather than building parallel intelligence records per regime. The operating discipline is one record, many reads.

Six Common Operating Pitfalls

Programmes that build the operating model from scratch tend to hit the same pitfalls. Naming them ahead of the build saves the rebuild.

Treating the sources as parallel scores. A programme that adds the CVSS base, the EPSS score, and the KEV flag into a composite number loses the reasoning chain and tends to discover that the composite hides which signal is driving the tier. The ordered tier rule preserves the chain.
Ignoring the inventory side. The KEV catalogue lists thousands of CVEs the enterprise estate does not contain. Programmes that treat KEV as a priority list rather than a CPE filter on the inventory burn triage capacity on CVEs that do not apply.
Picking an arbitrary EPSS threshold. EPSS at the 50th percentile and EPSS at the 95th percentile produce wildly different tier-one cohorts. The threshold is a programme calibration decision and the quarterly review reads it against the operating outcome.
Running the enrichment as a one-time intake snapshot. EPSS drifts daily, the KEV catalogue grows weekly, and vendor advisories republish without warning. The cadence has to re-enrich the open backlog rather than freezing the intake-day snapshot.
Treating vendor advisories as a nice-to-have. Vendor severity tends to lead the public CVE timeline and the operating model that waits for NVD entry to act on a vendor-named critical issue gives up the lead time. Vendor advisories sit on the watch list for every product class on the inventory.
Skipping the exception register. A programme that cannot meet the SLA on a tier-zero finding tends to leave the finding open rather than record the exception, and the audit lookback reads a silent backlog instead of a named risk acceptance. The exception register is the structural mechanism that converts the silence into a defensible decision.

None of the pitfalls is fatal on its own. Together they describe a programme operating an intelligence subscription rather than an intelligence discipline. The pitfalls list is the checklist the quarterly review reads against the operating data.

A Five-Week Rollout for an Internal Programme

The operating model can be built in five weeks against a workspace that already runs a vulnerability management cadence. The rollout is sequential because each week establishes the substrate the next week operates against.

Week 1: Source list and watch list

Catalogue the six source families. Write the source list with the named owner per source, the refresh cadence per source, and the inventory-scope filter per source. Build the vendor advisory watch list against the deployed product inventory. Publish the source list on the workspace as the operating reference.

Week 2: Enrichment workflow

Land the six enrichment steps as a standard intake pipeline on the workspace. Use bulk finding import to land KEV-aligned findings, EPSS-enriched findings, and vendor advisory references against asset bindings. Validate that the enrichment fields land on the finding record on every new intake.

Week 3: Decision rule and policy library

Write the five-tier decision rule. Settle the EPSS thresholds, the critical asset class list, and the vendor-named-exploitation rule. Publish the policy library on the workspace. Run the rule against the existing open backlog and migrate tier assignments onto the live findings view.

Week 4: Cadence and exception path

Stand up the intra-day cadence for KEV additions and the daily cadence for EPSS refreshes. Run the first weekly review against the live record. Stand up the exception register with the renewal cadence. Land the first set of named residual risk acceptors.

Week 5: Audit crosswalk and reporting

Land the framework crosswalk against the operating record. Generate the first monthly programme review pack from the workspace. Validate that the same record answers the first audit-style read (typically SOC 2 CC7.1 or ISO 27001 Annex A 8.8). Lock the operating model documentation set on the workspace.

Programmes that need to compress the rollout to three weeks can do so by limiting the source list to the first three families (exploitation evidence, exploitation prediction, identifier authority) and adding the vendor advisory and threat reporting families in a second iteration. Programmes that stretch the rollout beyond eight weeks tend to lose executive sponsorship before the cadence lands. The signal that the rollout is working is the audit-readable record growing weekly on the workspace rather than the slide deck count.

How SecPortal Supports the Operating Model

SecPortal gives the operating model a single workspace where the enrichment record lives. The platform does not author the policy library, set the EPSS threshold, or sign the exception; those are decisions the organisation makes. It does keep the enrichment workflow, the tier queues, the cadence reviews, and the audit evidence on one auditable record rather than across spreadsheets, ticket trackers, and intelligence portals.

On the intake side, findings management holds the CVE identifier, the CVSS 3.1 and 4.0 vectors, the CWE reference, the severity, the asset binding, and the source evidence on every finding. Bulk finding import lands large enrichment passes against existing findings without forcing per-finding manual entry. External scanning and authenticated scanning generate the source CVE intake stream the enrichment workflow runs against. Code scanning adds the SAST and SCA stream so dependency CVEs land on the same record as infrastructure CVEs.

On the operating side, finding overrides record the false-positive, accepted-risk, and severity-recalibration decisions with named attribution. Finding comments and collaboration anchor the triage and remediation conversation to the record. Retesting workflows close the loop with verified remediation. The activity log captures every state change with named participant and timestamp, with CSV export for audit reads. Continuous monitoring with scheduled scans keeps the intake stream refreshed on the daily and weekly cadences without manual triggers.

On the governance side, team management with RBAC assigns named owners across the source families and tier queues with permissions scoped to operational reality. MFA enforcement protects the workspace against account compromise. Notifications and alerts drive the cadence reviews and the exception renewal cycle on the workspace rather than across chat threads.

On the reporting side, AI report generation produces the monthly programme review pack and the audit committee read from the same engagement data. Compliance tracking feeds the framework crosswalk that the audit and evidence role maintains. Global search reads the workspace as a single body of evidence so the customer assurance pack and the audit fieldwork response work against one record. The platform is the operating substrate; the source list, the threshold, the decision rule, and the policy library are decisions the organisation makes once and reads from the workspace every cadence cycle.

Putting It Together

The vulnerability intelligence operating model is a structural answer to a coordination problem. The enterprise subscribes to four or more intelligence sources without a written rule for how the sources combine, and the audit committee asks which source is the enterprise position. The operating model writes the rule, lands the enrichment on the finding record, runs the cadence against the workspace, and produces audit-ready evidence the framework crosswalk reads in a single pack.

The build is five weeks against a workspace that already runs a vulnerability management cadence. The signal that the build is working is not the source count, the dashboard count, or the meeting count. It is the open backlog showing the named tier assignment with the enrichment trail visible to every triage analyst and every audit reader. Programmes that do the structural work and let the cadence drive the record produce an operating model that survives source-feed outages, leadership change, audit fieldwork, and regulator inquiry. Programmes that skip the structural work tend to discover the gap at the worst moment, when a KEV-listed finding lands on the audit committee read and the rationale chain cannot be reconstructed.

The next step is concrete. Catalogue the source list. Write the decision rule. Land the enrichment workflow against the live findings view. Run the daily cadence for two weeks against the same record the audit committee reads. The operating model starts the moment the record starts.

Run vulnerability intelligence on one workspace, not four portals

SecPortal consolidates findings management, bulk finding import, finding overrides, retesting, activity log, AI reporting, compliance tracking, and notifications on one workspace. The enrichment workflow runs against the same record the audit committee reads.

Get Started Free See Findings Management

No credit card required. Free plan available forever.