Asset criticality scoring
put a defensible tier on every asset before the queue has to decide
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.
No credit card required. Free plan available forever.
Score every asset before the queue has to ask which finding matters most
Vulnerability prioritisation depends on a multiplier the queue cannot derive from the scanner output alone: how important the underlying asset is to the business. A CVSS 7.5 finding on a customer-data system is a different decision than a CVSS 7.5 finding on a sandbox the build pipeline rebuilds every night. Without a defensible tier on the asset, the queue defaults to creation date or to a single severity number, the SLA system has no anchor for the immediate tier, and the leadership read of the breach metric describes operational thrashing rather than risk reduction. Asset criticality scoring is the discipline that captures the tier, the rationale, and the tier-to-SLA mapping on the engagement so every finding inherits the right tier without a manual classification step.
This is the upstream layer that prioritisation, SLA management, and leadership reporting all depend on. For the layer that records who owns each asset, read the asset ownership mapping workflow. For the queue ordering that uses tier as one signal alongside CVSS, EPSS, and KEV, read the vulnerability prioritisation workflow. For the deadline enforcement that translates tier into measurable closure windows, read the vulnerability SLA management workflow. For the queue-level visibility that catches aged findings on tier-zero assets, read the vulnerability backlog management workflow. For the closure event that retires the tier record, read the asset decommissioning and finding retirement workflow.
A four-tier framework most programmes settle on
The four-tier framework below is the steady starting point for most enterprise programmes. Each tier carries a written description, an example asset class, the SLA tier it maps to, and the rationale dimensions that drove the assignment. Programmes that need a fifth tier for archived or decommissioning candidates extend with tier four; programmes that try to run with three tiers tend to lose the meaningful distinction between tier zero and tier one, which is the distinction the SLA system most depends on.
Tier 0Crown jewels
Systems whose loss, corruption, or compromise materially threatens the business: customer-data systems with regulated data, payments and revenue systems, identity and authentication systems, production-control systems for the primary product, and the systems that hold the encryption keys protecting the rest. Tier-zero assets earn the tightest SLA tier, the most defensive scanning cadence, and the most senior named owner. The tier-zero list is short by design and is reviewed against business impact rather than scanner output.
Examples: Customer database, payment processor, identity provider, primary product backend, key management service, source of truth for financial reporting.
Tier 1Business essential
Systems that support the primary business workflow but whose loss is recoverable inside a defined recovery window without immediate revenue or regulatory impact: customer-facing applications outside the core transaction path, internal applications that power core business operations, supporting data stores, and integration services that brokered traffic to tier-zero systems. Tier-one assets earn a strong SLA tier and routine remediation prioritisation; downtime is uncomfortable but not existential.
Examples: Customer-facing marketing site, internal HR system, internal finance system, internal CRM, support ticketing, internal collaboration platform that holds business data.
Tier 2Operational
Systems that support internal operations but are not customer-facing and do not hold regulated data: developer tooling, internal documentation, operational dashboards, build infrastructure, monitoring stacks, and supporting services that compose the platform. Tier-two assets earn the standard SLA tier with normal remediation cadence; the failure mode is operational disruption rather than customer impact or regulatory exposure.
Examples: CI/CD runners, internal wiki, observability dashboards, developer sandbox environments, internal staging systems, build artefact registry.
Tier 3Low impact
Systems whose compromise produces a contained operational impact: ephemeral test environments, non-production sandboxes, marketing and content sites with no transactional capability, asset shells with no data, and decommissioning candidates. Tier-three assets earn the relaxed SLA tier and remediation in the standard maintenance window. The tier exists so the queue does not waste cycles treating low-impact findings as if they were business critical.
Examples: Marketing landing pages, ephemeral preview environments, isolated proof-of-concept hosts, decommissioning candidates running an end-of-life service tier.
Six dimensions every tier rationale has to cover
A tier assignment without a rationale is a vote rather than a control. The six dimensions below are the inputs every defensible tier rationale captures so the audit lookback can reconstruct the decision and the quarterly review either confirms or re-tiers with a documented reason.
Data sensitivity
The most regulated or business-sensitive data class the asset stores or processes: regulated personal data (PII, PHI, payment card data), authentication secrets, encryption keys, financial reporting data, intellectual property, internal-only operational data, public data. Data class is the strongest single contributor to the criticality decision because it is the dimension regulatory and contractual obligations attach to.
Business impact of loss
The realistic blast radius if the asset is unavailable, corrupted, or compromised: revenue impact per hour of downtime, regulatory or contractual penalty exposure, customer trust impact, recovery effort, downstream service degradation. Business impact is captured against the asset on the engagement so the criticality decision references a concrete impact narrative rather than a generic severity adjective.
Exposure
The reachability of the asset from an unauthenticated attacker: internet-facing services, services reachable from a partner network, internal-only services with limited reach, internal services with broad reach, services reachable only by named maintenance accounts. Exposure interacts with the data and impact dimensions to produce the residual risk profile, and it should be captured as an annotation on the asset rather than inferred per finding.
Compensating controls
Layered defences that demonstrably reduce the residual risk from a finding on the asset: network segmentation that constrains the blast radius, WAF rules that block the named exploit class, monitoring rules that detect the named exploitation pattern, session policies that constrain credential reuse, and isolation primitives that contain a compromise. Compensating controls are recorded with a rule, segment, or query reference rather than as a generic claim.
Recovery posture
The maturity of the recovery primitive for the asset: tested backup-and-restore, point-in-time restore, automated failover, manual failover, no defined recovery. Recovery posture interacts with impact: a tier-zero asset with a tested ten-minute RTO carries different residual exposure than a tier-zero asset with a manual recovery taking several days, even when the data class and exposure are identical.
Dependent surface
The downstream surface that depends on the asset: services that fail when this asset is degraded, customers affected when this asset is unavailable, internal teams blocked when this asset is offline. Dependent surface escalates criticality on assets that look operational in isolation but anchor the rest of the platform. The dependency graph is captured against the asset on the engagement so the routing layer respects the second-order impact.
Six drift patterns the criticality layer produces by default
Drift in the asset-tier mapping is the default state, not the exception. The six patterns below recur in every programme that grows past a few hundred assets. Each one starts as an operational convenience and ends as a routing-layer failure mode the leadership team only sees as SLA breach concentration on the wrong tier.
| Pattern | Healthy posture | Default failure |
|---|---|---|
| The criticality decision lives in a separate spreadsheet | The asset tier is captured against the engagement scope so every finding logged on the asset inherits the tier. The tier is a queryable property on the canonical asset record rather than a column in a sheet maintained outside the workflow. The queue and the criticality view always read from the same record. | A separate spreadsheet lists tier-zero, tier-one, and tier-two assets, but the finding queue does not pull from it. The result is a queue where tier-zero criticals sit alongside tier-three mediums in creation-date order, and the operator has to look up the tier per finding before deciding what to remediate first. |
| Tier is set once at onboarding and never reviewed | Asset tier is reviewed on a documented cadence with a named reviewer (quarterly is the steady cadence; monthly during onboarding pushes, platform migrations, or business reorganisations). Re-tiering events land on the activity log with the previous tier, the new tier, the reason, and the count of findings re-prioritised under the new tier. | The criticality decision was made when the asset was first onboarded and never refreshed. A system that was tier-three at launch is now the customer-facing checkout backend; a system that was tier-zero is now a decommissioning candidate. The queue still treats both at their original tier, and the SLA breach metric reads as remediation failure when the failure was an unrefreshed tier. |
| The same asset carries different tiers in different systems | The canonical asset identifier and the canonical tier live on the engagement record. Scanner outputs, vulnerability tickets, business-continuity plans, and audit evidence all reconcile against the same record so the answer to what tier this asset is is one query rather than a multi-system reconciliation. | The vulnerability tool calls a host tier-two; the business continuity plan calls the same host critical; the change-management system calls it standard. Each system carries a partial view of criticality and disagrees with the others. The auditor reads the disagreement as an undocumented control gap. |
| Tier is inferred from the scanner output | Asset tier is a deliberate business decision recorded by a named owner, not an artefact of how a scanner classified the host. The scanner output describes findings on the asset; the criticality record describes the asset itself. The two are kept separate so a scanner relabelling a host does not silently change the routing tier. | The criticality decision is a derived value from scanner severity, scanner asset categorisation, or a tag the scanner emits. A scanner update that changes how it labels hosts silently changes the queue priority. The leadership team does not realise the prioritisation queue moved; they read it as new findings. |
| Shared assets carry one tier when they should carry the highest of the dependent tiers | A shared platform service inherits the highest criticality of the systems that depend on it. The dependency graph is captured against the asset so a shared identity provider used by both tier-zero and tier-three workloads is treated at the tier-zero floor rather than at an averaged middle tier. The lead owner and coordinating committee are the same primitives the ownership map uses. | The shared identity provider is tagged as platform infrastructure at tier-two because the platform team owns it, even though both the tier-zero customer-data application and the tier-three internal sandbox depend on it. A finding on the identity provider lands at tier-two SLA when its compromise would breach the tier-zero workload, and the SLA metric reads cleanly until the audit lookback catches the dependency. |
| The tier list is opinion rather than evidence | Each tier assignment carries a written rationale citing the data class, the business impact, the exposure, the compensating controls, the recovery posture, and the dependent surface. The rationale is the audit-readable record of why the asset earned the tier; quarterly review either confirms the rationale still holds or re-tiers with a documented reason. | The tier list is a column in a spreadsheet with no rationale. When an auditor or new analyst asks why the customer-data store is tier-one rather than tier-zero, the answer is institutional memory that nobody can reconstruct. Re-tiering arguments become political rather than evidence-led, and the next reorganisation rewrites the list with no traceability. |
Six failure modes that quietly break the criticality layer
Criticality failures rarely look like failures at the moment they happen. They look like sensible defaults: collapse the framework into a single number, let every business owner argue for tier zero, infer the tier from the scanner. The cost arrives when the next reorganisation rewrites the asset list and the audit committee asks for the rationale behind a tier that was set five years ago.
Criticality is treated as a single number
Reducing the criticality decision to a single score (1 to 5, low to critical) flattens the underlying signals (data sensitivity, business impact, exposure, compensating controls, recovery posture, dependent surface) into a number that nobody can audit and few operators trust. The tier framework holds because each tier ties back to a named data class, business impact narrative, exposure profile, and recovery posture; the single-number alternative reads as a vote rather than a control.
Every system gets called critical
When every business owner argues their system is critical, the tier ceases to drive prioritisation. A defensible programme treats tier zero as a small, defensible list (often single digits to low double digits) where the loss is materially business threatening. Inflating the tier-zero list past the team capacity to defend it deflates the meaning of the tier and erodes the SLA system that depends on it.
Criticality is recorded against the wrong primitive
Capturing criticality against the engineering ticket, the scanner output, the change record, or the team rather than against the asset itself produces a tier that does not survive when the team rotates, the ticket closes, or the scanner is replaced. The asset is the durable primitive; the tier lives against the asset on the engagement record so the next finding inherits the tier without a manual decision.
Application criticality is conflated with infrastructure criticality
A tier-zero application running on tier-two infrastructure does not make the infrastructure tier-zero unless the dependency graph requires it. A defensible programme separates the application-level tier from the infrastructure-level tier and records the dependency relationship so a finding on the infrastructure escalates to the application tier when the dependency is load-bearing and stays at the infrastructure tier when it is not.
The criticality decision excludes the business owner
A tier assigned by the security team alone is a tier the business owner has not committed to defending. When the business owner is in the loop on the rationale, the SLA they will be measured against, and the compensating controls they need to maintain, the tier becomes a contract rather than a security-team opinion. Tiers without business commitment surface later as escalations the security team cannot escalate.
Re-tiering happens silently
When the criticality field changes on an asset without an activity-log entry, the previous tier has no audit-readable reason for the change. Reassignment becomes a routing decision with no provenance. Audit committees expect the trail to show who re-tiered, when, and why; a silent field edit reads as an undocumented control change.
Six fields every criticality policy has to record
A defensible criticality policy is six concrete fields on the engagement record, not an abstract paragraph in a security handbook. Anything missing from the list below is a known gap in the prioritisation primitive rather than a detail that surfaces later when a finding cannot be tier-assigned.
Tier framework definition
The four to five tier definitions the programme uses (commonly tier zero through tier three, sometimes tier four for archived or decommissioning candidates), each with a written description, an example asset class, and the SLA tier it maps to. The framework is the contract between the criticality decision and the SLA system; without it, every conversation about whether an asset is critical re-litigates the framework rather than the specific asset.
Per-asset tier rationale
Each tier assignment carries a written rationale referencing the six scoring dimensions: data sensitivity, business impact of loss, exposure, compensating controls, recovery posture, and dependent surface. The rationale is the audit-readable record of why the asset earned the tier and the input the quarterly review reads to either confirm or re-tier.
Named business owner accountability
Each asset carries the named business owner accountable for the tier and the named security contact accountable for the routing decisions. The business owner is in the loop on the SLA tier their asset earns, the compensating controls assumed in the tier rationale, and the change events that would trigger a re-tier. The accountability split keeps the criticality decision from being a security-team opinion.
Re-tiering cadence and triggers
How often the tier list is reviewed (quarterly is the steady cadence), who runs the review, and what triggers an out-of-cycle re-tier (a business reorganisation, a platform migration, a new regulated data class, a major compensating-control change, a recovery-posture downgrade, an asset retirement). The cadence is recorded on the engagement so a re-tiering cycle does not silently lapse.
Dependency-driven tier inheritance
The rule for shared and platform assets: an asset inherits the highest tier of the systems that depend on it unless a documented compensating control breaks the inheritance. The dependency graph is captured against the asset so the routing layer respects the second-order impact and the auditor can read why a shared service carries a different tier than its standalone description would suggest.
Tier-to-SLA mapping
The explicit mapping from tier to SLA tier: tier zero maps to the immediate SLA tier (often 24 to 72 hours for critical findings), tier one to the strong tier, tier two to the standard tier, tier three to the relaxed tier. The mapping is recorded so the SLA system reads the tier from the asset rather than asking operators to set it per finding, and the breach metrics roll up consistently.
Asset criticality scoring checklist
Before any cycle opens, and at every quarterly review, the security lead and the responsible business owners walk through a short checklist. Each item takes minutes; missing any one is the source of the failure modes above and the audit gaps that follow.
- The tier framework definition (four to five tiers) is documented on the engagement with descriptions, examples, and SLA mapping.
- Every asset on the engagement scope carries an explicit tier assignment.
- Each tier assignment has a written rationale citing data sensitivity, business impact, exposure, compensating controls, recovery posture, and dependent surface.
- The tier-zero list is short, defensible, and small enough for the team to actually defend.
- Each asset carries a named business owner accountable for the tier and a named security contact accountable for routing.
- Tier inheritance for shared and platform assets follows a documented dependency rule rather than informal practice.
- Tier review runs on a documented cadence (quarterly is steady) with a named reviewer.
- Out-of-cycle re-tiering triggers are documented and observed when they fire.
- Re-tiering events land on the activity log with the previous tier, the new tier, the reason, and the count of findings re-prioritised.
- The tier-to-SLA mapping is explicit so the SLA system reads tier from the asset rather than per finding.
- Tier coverage is reported alongside SLA, backlog, and aging metrics on the leadership cadence.
- Activity log exports cover ISO 27001 Annex A 5.9, 5.12, and 8.8, SOC 2 CC3.x, PCI DSS 6.3.1 and 12.4, NIST SP 800-53 RA-2 and CM-8, and CIS Controls v8 Safeguards 1.1 and 7.1.
How asset criticality scoring looks in SecPortal
Criticality scoring runs on the same feature surfaces the rest of the vulnerability programme already uses: the engagement record, the findings record, the activity log, AI reporting, and the team management layer. The discipline is keeping the tier and the rationale queryable on the engagement so the next finding inherits the tier rather than waiting for a manual decision.
Tier on the engagement scope
The tier framework definition, per-asset tier assignment, written rationale, named business owner, and re-tiering cadence sit on the engagement record. Findings logged against the engagement inherit the tier so prioritisation reads it without an external lookup.
Tier on the finding
Findings management holds the asset reference, the inherited tier, and the resulting SLA tier on the security record. Re-tier events are captured as state changes with the previous tier, the new tier, and the reason rather than as silent field edits.
Anchor identity to verified domains
Internet-facing services are tied to verified domains, so the canonical asset identifier the tier attaches to is the verified domain rather than a free-text host string a scanner emitted differently across runs. The verification primitive doubles as the join key for tier records.
Routing tier feeds the SLA timer
The tier-to-SLA mapping is read by the SLA layer at finding creation so the SLA timer starts on the right deadline. The deadline rolls up into the breach metric broken out by tier so the leadership team can see whether a breach pattern is concentrated at tier zero (capacity) or tier three (tier inflation).
RBAC scoped to the named owner
Team management grants the named business owner the scope to see and update findings on their assets without exposing the rest of the programme. The criticality decision and the access decision stay consistent on the same workspace.
Audit trail in the activity log
Every re-tiering event, rationale update, named-owner change, and SLA-mapping adjustment lands on the activity log with timestamp and user attribution. The CSV export is the evidence trail ISO 27001, SOC 2, PCI DSS, NIST, and CIS assessors expect when they ask how the categorisation primitive is maintained.
Five reporting views the criticality cycle actually drives
The reports that drive criticality scoring are not the static document that lands at the end of a quarter. They are the live views operators, security leads, and audit committees use between meetings. The five below are the ones every meaningful programme settles on, and they all derive from the live engagement record rather than a parallel inventory extract.
Tier coverage by asset class
Assets with an explicit tier assignment broken out by asset class (verified domain, repository, cloud resource, internal host, shared dependency). The view that tells the leadership team whether the criticality primitive can answer the routing question for the next finding without a manual lookup.
Tier distribution against business expectation
The count of assets at each tier compared against the business expectation. A tier-zero list that grows past single digits warrants a review of whether the tier definition is being applied consistently. A tier-three list that is empty warrants a review of whether the framework is being used or quietly defaulted to a higher tier.
Re-tiering history
Re-tiering events over the reporting period with the previous tier, the new tier, the reason, the named reviewer, and the count of findings re-prioritised. The view that catches drift before the next audit lookback reads it as a silent tier change.
SLA breach by tier
Open and closed SLA breaches broken out by tier so the leadership team sees whether the breach pattern is concentrated in tier-zero (a programme-capacity problem), tier-three (a tier-inflation problem), or evenly distributed (a routing problem). The breakdown is the diagnostic the breach metric alone cannot supply.
Dependency-tier inheritance map
The shared and platform assets that inherit a higher tier from their dependents, with the inheritance reason and the tier they would otherwise carry on their standalone description. The view that keeps the dependency-inheritance rule observable rather than buried in the rationale fields.
What auditors expect from an asset criticality programme
Criticality evidence shows up in audit reads whenever an external assessor reviews the asset management or the vulnerability programme. The frameworks below all expect the inventory to identify the classification or risk rank and the remediation timeline to match the classification. A documented framework without an enforcement record reads as a process gap rather than as a control.
| Framework | What the audit expects |
|---|---|
| ISO 27001:2022 | Annex A 5.9 (inventory of information and other associated assets), 5.12 (classification of information), and 8.8 (technical vulnerability management) together expect the asset inventory to identify assets, their classification, and the remediation timeline. The tier framework, the per-asset rationale, and the tier-to-SLA mapping satisfy the classification and timeline controls without requiring a parallel spreadsheet extract. |
| SOC 2 | Common Criteria CC3.x expects identification and assessment of risk; CC7.x expects detection and response on a defined timeline. The criticality framework is the risk-identification primitive that connects the asset to the remediation timeline. Programmes that operate without a documented tier framework cannot produce the risk-ranking evidence CC3.x reviewers ask for at the operating-effectiveness phase. |
| PCI DSS | Requirement 6.3.1 expects a process for identifying security vulnerabilities and assigning a risk ranking based on industry best practices, and Requirement 12.4 expects assignment of information security responsibilities. The combined criticality framework, per-asset rationale, and named-owner accountability satisfy both controls together; the assessor reads the tier framework as the documented risk ranking and the activity log as the assignment trail. |
| NIST SP 800-53 | Controls RA-2 (security categorization) and RA-3 (risk assessment) expect the system to be categorised by impact level and the residual risk to be assessed. Control CM-8 (system component inventory) expects ownership and accountability against each component. The criticality framework is the categorisation primitive; the per-asset rationale is the risk-assessment narrative; the dependency-driven inheritance handles the second-order impact NIST RA-2 reviews surface. |
| CIS Controls v8 | Safeguard 1.1 expects an enterprise asset inventory and Safeguard 7.1 expects a documented vulnerability management process with a named owner. The criticality framework is the connection between the inventory primitive (Safeguard 1.x) and the remediation primitive (Safeguard 7.x). The tier-to-SLA mapping turns the inventory categorisation into the remediation timeline the safeguards expect. |
Where criticality scoring sits in the vulnerability lifecycle
Criticality scoring is the upstream layer that prioritisation, SLA management, backlog management, and leadership reporting all depend on. It composes with the rest of the vulnerability lifecycle on the same engagement record so the categorisation primitive stays connected to the routing layer downstream and the inventory layer upstream.
Upstream and adjacent
Criticality scoring builds on asset ownership mapping (the same canonical asset record carries both ownership and tier), scanner result triage (validated findings inherit the asset tier), and scanner to ticket handoff governance (the routing rule respects the tier when deciding which queue receives the ticket).
Downstream and reporting
Tier evidence rolls up into vulnerability prioritisation (tier is the multiplier the queue applies), vulnerability SLA management (tier reads as the SLA tier the timer starts on), vulnerability backlog management (tier reads as a queue-health indicator), and security leadership reporting (tier coverage and breach-by-tier are headline indicators on the leadership cadence).
Pair the workflow with the long-form guides and the framework references
Criticality scoring is operational; the surrounding guides explain the rationale model, the buyer logic, and the audit expectations the categorisation layer has to satisfy. Pair this workflow with the vulnerability prioritisation framework guide for the broader prioritisation context, the vulnerability management programme guide for the programme view, and the risk-based vulnerability management buyer guide for the buyer-and-procurement view of the discipline. The framework references that mandate asset categorisation include ISO 27001 for asset inventory and information classification, SOC 2 for risk identification and response, PCI DSS for documented risk ranking, and NIST SP 800-53 for security categorization (RA-2) and risk assessment (RA-3).
Buyer and operator pairing
Asset criticality scoring is the workflow vulnerability management teams run as the categorisation primitive of the programme, internal security teams run alongside ownership mapping and SLA management, AppSec teams run for the application portfolio, cloud security teams run for the cloud-resource tier framework, and GRC and compliance teams run for the audit evidence the categorisation layer produces. CISOs and security operations leaders read tier coverage, tier distribution, and SLA breach-by-tier as the leading indicators of whether the prioritisation primitive is healthy.
What good criticality scoring feels like
Every finding inherits a tier
The asset reference resolves to a tier as the finding is created. The prioritisation queue does not pause for a tier lookup because the categorisation primitive already answered the question.
Re-tiering is a quarterly event
The tier list is reviewed on a documented cadence with a named reviewer and the business owner. Reorganisations and platform migrations land as a single re-tiering event rather than as a per-finding propagation problem.
Tier zero is small and defensible
The tier-zero list is short enough that the security team and the named business owners can credibly defend every system on it at the immediate SLA tier. Tier inflation is caught in review rather than in audit.
Audit reads from one record
The framework, the per-asset tier, the rationale, the re-tiering history, and the SLA-by-tier breach metric all read from the live engagement record. ISO 27001, SOC 2, PCI DSS, NIST, and CIS assessors get the evidence as a query rather than a multi-week reconciliation sprint.
Asset criticality scoring is the categorisation primitive that prioritisation, SLA management, backlog management, and leadership reporting all depend on. Run it on the engagement record so every finding inherits a defensible tier, the re-tiering events are reproducible, the breach metrics roll up against the categorisation, and the audit lookback resolves from one record rather than a multi-system reconciliation sprint.
Frequently asked questions about asset criticality scoring
What is asset criticality scoring for vulnerability management?
Asset criticality scoring is the operating discipline that classifies each asset (host, application, repository, cloud resource, dependency) into a small, defensible set of tiers (commonly tier zero through tier three) so vulnerability findings are prioritised and SLA-tracked according to the business impact of the asset, not just the technical severity of the finding. The framework combines data sensitivity, business impact, exposure, compensating controls, recovery posture, and dependent surface into a written tier rationale per asset. SecPortal records the tier and rationale on the engagement so every finding inherits the tier without manual classification.
How is asset criticality scoring different from vulnerability prioritisation?
Vulnerability prioritisation orders the queue by combining technical severity (CVSS), exploit likelihood (EPSS), active exploitation status (CISA KEV), asset criticality, exposure, and compensating controls into a single ranked list. Asset criticality scoring is the upstream layer that decides how important the asset is so prioritisation has a multiplier to apply. The two compose. Criticality scoring decides which assets matter most. Prioritisation orders findings on those assets by signal strength.
How is asset criticality scoring different from asset ownership mapping?
Asset ownership mapping records who is accountable for the asset; asset criticality scoring records how important the asset is. The two are paired: the named owner is the routing target for findings, and the criticality tier is the SLA tier the routing target is held to. Programmes typically run them together on the engagement record so a single canonical asset reference carries both the ownership mapping and the criticality tier and the next finding inherits both at creation rather than per-finding lookup.
How many tiers should the framework use?
Four tiers (zero through three) is the steady framework for most programmes. Five tiers (adding a tier four for archived, decommissioned, or asset shells with no data) shows up in larger programmes that need a separate disposition for retired assets. Three-tier frameworks (high, medium, low) tend to collapse the meaningful distinction between tier zero (business threatening) and tier one (business essential), which is the distinction the SLA system most needs to read. Avoid frameworks beyond five tiers; the cost of operator memory exceeds the benefit of finer granularity.
How small should the tier-zero list be?
Tier zero should be small enough that the security team and the named business owners can credibly defend every system on the list at the immediate SLA tier. Single digits is common in mid-sized programmes; low double digits is common in larger enterprises. Inflating the tier-zero list past the team capacity to defend it deflates the meaning of the tier and erodes the SLA system that depends on it. If everything is critical, nothing is.
How often should asset tiers be reviewed?
Quarterly is the steady cadence for most programmes; monthly is appropriate during platform migrations, business reorganisations, major application onboardings, or regulated data class changes. Out-of-cycle re-tiering is triggered by named events (a reorganisation, a new regulated data class, a major compensating-control change, a recovery-posture downgrade, an asset retirement, a dependency-graph shift). The re-tiering event lands on the activity log with the previous tier, the new tier, the reason, and the named reviewer.
How does criticality scoring interact with shared and platform assets?
Shared assets and platform services inherit the highest criticality of the systems that depend on them, unless a documented compensating control breaks the inheritance. The dependency graph is captured against the asset on the engagement so a shared identity provider used by both a tier-zero workload and a tier-three workload is treated at the tier-zero floor rather than at an averaged middle tier. The lead owner and coordinating committee primitives from the asset ownership mapping carry through to the criticality decision so the routing and tier records use the same shared-asset rule.
Does SecPortal include a built-in asset inventory or business impact analysis tool?
SecPortal records assets as part of the engagement (engagement targets, verified domains, scanner outputs, finding asset references) but does not synchronise with an external CMDB or run a business impact analysis on the user behalf. The criticality tier and rationale are captured as structured metadata on the engagement so the tier is queryable from the same record the findings live on. Programmes that already operate a separate CMDB or business impact analysis register use SecPortal as the canonical tier record for the security routing layer and reconcile against the upstream registers on a documented cadence rather than synchronously.
How does the tier framework map to SLA tiers?
The tier-to-SLA mapping is explicit and documented on the engagement: tier zero maps to the immediate SLA tier, tier one to the strong tier, tier two to the standard tier, tier three to the relaxed tier. The exact deadlines (24 hours, seven days, thirty days, ninety days, and so on) are programme-specific and should be calibrated against framework expectations such as PCI DSS 6.3.3 critical-vulnerability windows and the team capacity to deliver against the deadline. The mapping is read by the SLA system at finding creation so the SLA timer starts on the right deadline without operator intervention.
How does AI report generation handle the criticality narrative?
AI-generated reports derive the criticality narrative from the live record: the tier framework definition, the tier coverage view (assets with an explicit tier against assets with a missing or default tier), the tier distribution against business expectation, the re-tiering history over the reporting period, and the SLA breach pattern broken out by tier. The narrative lands in the report as derived prose rather than reauthored copy, and the headline numbers reconcile to the engagement record because the report is generated from the same source the routing and SLA decisions live on.
How it works in SecPortal
A streamlined workflow from start to finish.
Define a four-tier framework with explicit SLA mapping
Before any asset is scored, the programme commits to a small framework (commonly four tiers from tier zero crown jewels through tier three low impact, sometimes a fifth tier for archived or decommissioning candidates). Each tier carries a written description, an example asset class, and the SLA tier it maps to. The framework is the contract between criticality and SLA; without it, every conversation about whether an asset is critical re-litigates the framework rather than the specific asset. The framework lives on the engagement so the next finding inherits the tier-to-SLA decision rather than asking the operator to make it per finding.
Score each asset against the six rationale dimensions
Every asset on the engagement scope is scored against six dimensions: data sensitivity (the regulated or business-sensitive data class the asset handles), business impact of loss (revenue, regulatory penalty, customer trust, recovery cost), exposure (internet-facing, partner-reachable, internal broad reach, internal narrow reach), compensating controls (segmentation, WAF rules, monitoring, isolation), recovery posture (tested backup, automated failover, manual failover, no defined recovery), and dependent surface (the downstream services that fail when this asset is degraded). The combined rationale produces the tier assignment and the audit-readable record of why the asset earned the tier.
Resolve dependency-driven tier inheritance for shared and platform assets
Shared assets and platform services inherit the highest tier of the systems that depend on them, unless a documented compensating control breaks the inheritance. The dependency graph is captured against the asset on the engagement so a shared identity provider used by both a tier-zero workload and a tier-three workload is treated at the tier-zero floor rather than at an averaged middle tier. The lead owner and coordinating committee primitives from the asset ownership mapping carry through so the routing and tier records use the same shared-asset rule.
Tie each tier to a named business owner and a security contact
Every asset carries the named business owner accountable for the tier rationale and the named security contact accountable for the routing decisions. The business owner is in the loop on the SLA tier their asset earns, the compensating controls assumed in the rationale, and the change events that would trigger a re-tier. The accountability split keeps the criticality decision from being a security-team opinion the business has not committed to defending.
Run scheduled re-tiering reviews and capture every event on the activity log
The tier list is reviewed on a documented cadence (quarterly is the steady cadence; monthly during platform migrations, business reorganisations, regulated data class changes, or major application onboardings). Out-of-cycle re-tiering is triggered by named events (a reorganisation, a new regulated data class, a major compensating-control change, a recovery-posture downgrade, an asset retirement, a dependency-graph shift). The re-tiering event lands on the activity log with the previous tier, the new tier, the reason, the named reviewer, and the count of findings re-prioritised under the new tier.
Report tier coverage and SLA breach by tier as leadership metrics
Tier coverage (assets with an explicit tier against assets with a missing or default tier), tier distribution against business expectation, re-tiering history, and SLA breach broken out by tier land on the leadership dashboard alongside backlog, aging, and remediation-throughput metrics. The activity log CSV export covers ISO 27001 Annex A 5.9, 5.12, and 8.8, SOC 2 CC3.x, PCI DSS 6.3.1 and 12.4, NIST SP 800-53 RA-2 and CM-8, and CIS Controls v8 Safeguards 1.1 and 7.1 for the auditor read of how the categorisation primitive is maintained. AI-generated reports derive the criticality narrative from the same record so the leadership view and the audit view never disagree.
Features that power this workflow
Run asset criticality scoring on the engagement record
Score every asset into a four-tier framework with a written rationale across data, impact, exposure, controls, recovery, and dependents. Let the SLA system read the tier from the asset rather than asking operators to set it per finding. Start free.
No credit card required. Free plan available forever.