Rule

Configuration Baseline Rule

The codified standard configurations for each asset class — defining approved OS versions, required security settings, mandatory agents, network configurations, and hardening standards (CIS benchmarks, STIG) that every system must comply with, along with the exception process for justified deviations.

Last updated: February 2026Data current as of: February 2026

Why This Object Matters for AI

AI cannot detect configuration drift or enforce compliance without explicit baseline definitions; without them, 'is this server configured correctly' requires a security engineer to manually compare settings against a mental model of what 'correct' looks like, and drift accumulates invisibly.

Information Technology & Infrastructure Capacity Profile

Typical CMC levels for information technology & infrastructure in Manufacturing organizations.

Formality
L2
Capture
L2
Structure
L2
Accessibility
L2
Maintenance
L2
Integration
L2

CMC Dimension Scenarios

What each CMC level looks like specifically for Configuration Baseline Rule. Baseline level is highlighted.

L0

Configuration standards exist only in engineers' heads; 'correctly configured' means whatever the person who built it thinks is right, and no two servers are set up the same way.

None — AI has no baseline definitions to compare configurations against.

Document baseline configuration standards for each major asset class defining approved OS versions, required security settings, and mandatory agents.

L1

A wiki page lists recommended configurations for servers and workstations, but it's general guidance — 'keep systems patched' rather than specific required settings, and CIS benchmark references are mentioned but not mapped.

Can reference the guidance document but cannot determine whether a specific system is compliant without manual comparison.

Define specific configuration requirements per asset class — exact OS versions, required patch levels, security settings, and mandatory agents — in a structured checklist.

L2Current Baseline

Structured checklists define required configurations per asset class — OS versions, security settings, mandatory agents — but they're maintained as documents that require manual comparison against actual system state.

Can compare checklist items against reported configurations but cannot automate the comparison without manual system inspection.

Encode baselines as machine-readable rules that can be evaluated against system configuration data, with defined pass/fail criteria per setting.

L3

Baselines are encoded as structured rules per asset class with machine-readable settings, pass/fail criteria, and references to source standards (CIS benchmarks, STIG), enabling automated compliance checking.

Can automatically evaluate system configurations against baseline rules, generate compliance reports, and flag deviations with specific setting references.

Implement a validated baseline schema with versioned rule sets, exception management workflows, and automated remediation script references per deviation.

L4

A validated baseline schema defines versioned rule sets with exception workflows, remediation script references, and automated compliance scoring — deviations auto-generate remediation tickets with fix instructions.

Can auto-detect deviations, generate remediation plans with specific fix scripts, and predict compliance drift based on historical patterns.

Deploy adaptive baselines that auto-update rules when new security standards publish, new threats emerge, or vendor best practices change.

L5

Adaptive baselines auto-update when new CIS benchmarks publish, new CVEs affect configuration settings, or vendor best practices change — rule sets evolve continuously without manual revision.

Can autonomously maintain configuration standards, auto-update rules from external sources, and enforce compliance without human intervention.

Ceiling of the CMC framework for this dimension.

Capabilities That Depend on Configuration Baseline Rule

Other Objects in Information Technology & Infrastructure

Related business objects in the same function area.

IT Asset Inventory

Entity

The comprehensive registry of all IT assets — servers, workstations, network devices, cloud instances, and installed software including hardware specifications, operating system versions, patch levels, warranty status, assigned owner, and the relationships between assets that form the configuration management database (CMDB).

IT Service Ticket

Entity

The transactional record for each IT incident or service request — containing the reported issue, affected system, priority, category, assigned technician, resolution steps taken, time to resolution, root cause code, and user satisfaction rating tracked through the ITSM lifecycle.

Network and Infrastructure Topology

Entity

The structured map of how IT systems interconnect — defining network segments, VLANs, firewall zones, cloud VPCs, load balancer configurations, DNS records, and the dependency chains that show which applications rely on which infrastructure components.

User Identity and Access Profile

Entity

The managed record of each user's digital identity — containing authentication credentials, role assignments, group memberships, application entitlements, access request history, last login timestamps, and the privilege escalation audit trail maintained by identity and access management (IAM) systems.

Software License Portfolio

Entity

The managed inventory of software entitlements — containing license types (perpetual, subscription, usage-based), quantities purchased, quantities deployed, renewal dates, cost per license, vendor contract references, and the compliance position showing over- or under-deployment per product.

Security Threat Intelligence

Entity

The curated collection of known threat indicators, attack patterns, and vulnerability data — containing indicators of compromise (IOCs), Common Vulnerabilities and Exposures (CVEs), threat actor profiles, attack technique mappings (MITRE ATT&CK), and the risk scores that contextualize threats to the organization's specific environment.

Patch Deployment Priority Decision

Decision

The recurring judgment point where IT operations evaluates which patches to deploy and in what order — weighing vulnerability severity (CVSS score), exploit availability, asset criticality, production impact risk, maintenance window constraints, and testing completion status.

Security Incident Response Decision

Decision

The recurring judgment point where the security team determines the appropriate response to a detected threat — evaluating threat severity, confidence level, affected systems, containment options (isolate, block, quarantine), business impact of each response action, and the escalation criteria for invoking incident response plans.

Access Control Policy Rule

Rule

The codified rules governing who may access which systems under what conditions — defining role-based access templates, separation-of-duties constraints, privileged access requirements (MFA, just-in-time), periodic review schedules, and the automatic deprovisioning triggers for terminated or transferred employees.

IT Incident Management Process

Process

The end-to-end workflow governing how IT incidents are detected, triaged, escalated, resolved, and reviewed — defining severity classification criteria, response time SLAs per severity, escalation paths, communication templates, post-incident review requirements, and the knowledge base update triggers that capture resolution patterns.

What Can Your Organization Deploy?

Enter your context profile or request an assessment to see which capabilities your infrastructure supports.