Skip to content

Baseline Comparison & Implementation Plan

Setting-level technical evidence

Compare the approved company baseline to public technical profiles—without inventing a compliance score.

Begin with all 98 TMCO Consulting-approved rules, then switch among the pinned CIS, DISA STIG, NIST, CMMC, CNSSI, HICP, and NLLMAP technical profiles. Exact rule-ID overlap shows what the company baseline includes and what it would need to consider; only reviewed Intune joins produce deterministic posture. A profile comparison is not a certification or organizational verdict.

Open Mission Control Read the methodology Change the approved target safely
Current approved baseline: the pinned TMCO Consulting macOS 26 technical baseline. Reference profiles come from the same pinned public NIST mSCP revision. The comparison is exact profile membership—not a CIS, NIST, DoD, CMMC, HHS, or assessor score.
Loading the fingerprint-verified Mission package…

Approved baseline versus reference profile

Technical profile overlap

Exact rule-ID membership only. “Included” does not mean implemented, observed, satisfied, compliant, or assessed. Deterministic Intune evidence remains a separate state.

How to read the matrix

The default table shows every TMCO Consulting-approved rule. Changing the comparison profile also adds its reference-only rules so the adoption gap is visible rather than hidden. Select Review details for the exact provider definition ID when one is approved, public-safe policy references, evidence IDs, fingerprints, deterministic guidance, and limitations. Use Limit to deterministically evaluated rules to reduce the view to the four exact Intune joins.

A green technical-evidence state means the collected setting matched the approved target and had normalized assignment evidence. It does not prove the organization satisfies the mapped control. A drift state means the setting-level evidence needs review; interviews, procedures, scope, operating effectiveness, and assessor judgment may still be required for every framework.

Why the public site does not show tenant policy names

The production package is deliberately sanitized. Tenant display names, object IDs, group names, and assignment identities are excluded or pseudonymized before publication. The matrix therefore shows public-safe setting/evidence references rather than claiming to expose the tenant's actual Intune display names.

A private, access-controlled deployment can preserve a reviewed parent-policy reference and friendly name after a separate data-classification and authorization review. That parent-policy join is the next data-model priority; the public matrix never guesses it from a display name.

Coverage limits

  • The complete 98-rule TMCO Consulting-approved inventory is visible by default. Only explicitly reviewed exact provider mappings enter the technical-alignment denominator.
  • Sixteen pinned public mSCP reference profiles are loaded for exact rule-membership comparison, including CIS Levels 1 and 2, DISA STIG, NIST SP 800-171 and SP 800-53 impact levels, CMMC Levels 1 and 2, CNSSI impact levels, HICP, NLLMAP, and CIS Controls v8.
  • Implementation planning required means the rule belongs to the approved inventory but its Intune Settings Catalog, custom-profile, script/agent, or alternate-evidence path has not been approved. It is a backlog state—not a failed control.
  • Provider mapping review required means desired metadata exists but an exact Intune definition ID has not yet passed review.
  • STIG, NIST, CMMC, and other profile membership is loaded from the pinned mSCP source. Separate cross-reference cells are identifiers associated with an evaluated setting. Both are supporting technical evidence, not independent baseline scores.
  • Unsupported rules say so directly. AI does not create missing mappings or fill evidence gaps.
  • Provifact remains GET-only and cannot change, assign, or remediate an Intune policy.