Asset and user criticality
On this page
Not every alert deserves the same response. Criticality is a risk-based lens that weighs alerts by what they could affect and who is involved, so analyst time concentrates where it matters. Alert reads it to order the queue; Scope owns the classification.
How far to go in Alert
This page lives in Scope because Scope owns the classification, but Alert uses it first. In Alert, criticality is one lookup with a stopping point: read the existing tier for the asset and the account type for the identity, and let them order the queue. Criticality is a weighting, not a truth test: it says how much an alert matters, not whether it is real. Classifying assets is Scope’s job (see entity boundaries and infrastructure boundaries); Alert reads the classification that exists and flags gaps in the handoff. The fast-path depth ladder sets how much a given alert needs, and the Alert transition lists what to hand off.
How criticality validation works
Two alerts can be identical in content and very different in importance. An anomalous login to a developer’s sandbox account is one situation. The same anomalous login to a service account with administrative rights on the domain controllers Domain Controller A server that hosts the Active Directory database (NTDS.dit, including every account's password hashes) and runs the Kerberos KDC for its domain. It is Tier 0: an attacker with DC-level access, or replication rights used via DCSync, owns the domain. Any unexpected interactive logon, new service or replication request involving a DC warrants escalation. is another. Criticality validation is the strategy that builds this distinction into triage by attaching weights to the entities involved.
The strategy has two halves. Asset criticality Asset Criticality The level of importance or sensitivity of an asset, which determines the level of protection it requires. In ASSURED, asset criticality is one of the four RATM dimensions; with business impact it sets the impact axis (impact is the higher of the two). Score the highest-value asset in confirmed reach, not just the entry point. See the priority matrix. describes the business and operational importance of the systems involved. User criticality describes the privilege level, access scope, and authority of the identities involved. Together they produce a risk-weighted view of the alert that the analyst can use to allocate time proportionally.
Asset criticality
Assets are usually classified into tiers like Critical / High / Medium / Low, or scored numerically. The classification reflects three things:
Business value
Revenue impact if the asset is degraded, customer-facing visibility, contractual obligations. Revenue-generating systems and customer-data stores sit at the top of most classification schemes.
Regulatory exposure
Whether the asset stores or processes data covered by HIPAA, GDPR, SOX or sector-specific regulation, or by contractual regimes such as PCI DSS. Compliance-bound systems may demand investigation regardless of where they sit on the tier list.
Network and identity proximity
An asset is as critical as the most critical thing reachable from it, over the network or through credentials and permissions. A workstation where a domain admin logs on is Tier 0 in practice, and a low-tier workstation with direct access to the production database is no longer low-tier. Ask how many hops separate it from Tier 0 (domain controllers, identity-provider admins, the cloud organization root); attack-path tools such as BloodHound make these paths visible. Reachability raises the weighting and travels to Scope as a flag; on its own it does not set Level 2, which needs a crown-jewel subject, a privileged identity, or regulated data plausibly accessed by the activity under review.
User criticality
User accounts carry their own weight. Three factors define it:
Privilege level
Standard user, privileged user, service accounts and other non-human identities (cloud service principals, OAuth apps, API keys, automation and AI-agent identities). Each has a different blast radius if compromised. Non-human identities are especially important to model because they often outlive the people who created them. Privileged identities never qualify for a Level 0 close; they route to Level 2 on the depth ladder.
Access scope
How many systems and how much data the account can touch. A privileged user with narrow scope is less dangerous than a standard user with wide scope. Both are worth weighting.
Authority and exposure
What the person can approve or move (payments, payroll, access grants) and how attractive they are as a target (executives, finance approvers, public-facing staff). A CFO can authorize a wire with no admin rights at all.
Example: identical alerts, very different responses
Two anomalous logins
Two anomaly alerts fire at 03:00 reporting unusual login times. Both alerts look identical in shape. They are not equivalent in priority.
Alert 1: anomalous 03:00 login on a workstation belonging to a contractor account, a Low-criticality asset, no access to production systems. The contractor’s role is to maintain a single sandboxed application.
Alert 2: an interactive 03:00 logon by a service account that normally authenticates only non-interactively, and whose role includes administrative access to two domain controllers Domain Controller A server that hosts the Active Directory database (NTDS.dit, including every account's password hashes) and runs the Kerberos KDC for its domain. It is Tier 0: an attacker with DC-level access, or replication rights used via DCSync, owns the domain. Any unexpected interactive logon, new service or replication request involving a DC warrants escalation. and a database tier holding regulated patient data.
Without criticality validation, both alerts compete for the same investigator at the same time. With criticality validation, the analyst’s queue is automatically ordered: Alert 2 is investigated first, now; Alert 1 is queued for review during regular hours unless other signals raise it. Alert 2 also sets its own depth: a service account with administrative rights on domain controllers is a privileged identity, so it fails the Level 0 eligibility gate and routes to Level 2 on the depth ladder.
The validation logic is doing two things at once. It is sorting by potential impact, and it is providing the analyst with a defensible justification for the choice. Months later, in a post-mortem Post-Mortem The structured retrospective an organization runs after a closed incident: timeline, decisions, what worked, what failed, what the team learned. A good post-mortem points back at detection, process, or training gaps. A blameless one names the system, not the person. or an audit, the criticality data attached to the alert at the time of triage is what makes the prioritization decision reviewable.
Implementation requirements
Criticality validation is only as good as the data underneath it. Three sources matter most.
Asset inventory
A CMDB (ServiceNow, custom) or asset platform that knows every system, its classification, its owner, its data sensitivity, and its network position. The inventory should update as the environment changes.
Identity directory
Active Directory, Microsoft Entra ID, Okta, or equivalent, with an identity-governance platform such as SailPoint as the usual source of entitlements and account ownership. The directory should know account types, role assignments, group memberships, and the relationships between them. Service accounts and other non-human identities should be tagged separately, each with a named owner.
Compliance mapping
An explicit map of which assets and data flows are covered by which regulations. The map should be authoritative enough that an analyst can rely on it during triage without consulting legal counsel for every alert.
Operational practice
- Keep inventories current. Stale CMDB data degrades criticality scoring silently. The alerts still fire, but their priorities become wrong without anyone noticing for weeks.
- Define classification criteria clearly. “Critical” should mean the same thing in two different teams’ heads. A short documented definition with examples is worth the time.
- Re-classify during organizational change. Mergers, divestitures, system migrations, and major reorganizations all change criticality in ways that need to flow into the validation logic.
- Integrate compliance triggers explicitly. HIPAA-relevant systems may need investigation even when the tier score would not have demanded it. Make that rule visible in the validation logic rather than relying on analysts to remember it.
Key takeaway
Criticality validation is what keeps a SOC’s response proportional to risk as the environment grows. Without it, every alert competes equally for attention, and the most consequential intrusions get the same response time as the most routine ones. With it, analyst time concentrates where the cost of inattention is highest.
Next up
Infrastructure boundaries
Criticality says what is at stake. Infrastructure boundaries map how far the activity could reach across networks, cloud accounts and shared services.
Read infrastructure boundariesTechnical details verified . Product names, defaults and retention change; check your own tenant.