Systems & Objectives

Catalog the systems in your CUI environment, categorize each by its role in scope, and work every control objective against them — the day-to-day compliance work that drives your assessment, SPRS score, and SSP.

Systems & Objectives is where the bulk of your CMMC work actually happens. You start by cataloging every system in your environment — each computer, server, application, or service that touches, protects, or sits near your Controlled Unclassified Information (CUI). You then categorize each system by the role it plays in your CUI scope, and you work through the control objectives — the granular, testable sub-parts of each NIST SP 800-171 practice — recording how each one is implemented and attaching the evidence that proves it.

That objective-by-objective work is the raw material for everything downstream. Your assessment completion, your SPRS score, and your System Security Plan (SSP) are all derived from the statuses, narratives, and evidence you record here.

Find it in the sidebar under Systems (/dashboard/systems). Everyone with compliance-read access can view your systems and objectives; recording statuses, writing narratives, and attaching evidence require a working role — see Permissions.

Key concepts

A system

A system is any distinct piece of your environment you want to account for — a workstation fleet, a file server, a cloud application, a firewall, a piece of shop-floor equipment. Each system carries a name, a type, and — most importantly — a CUI scope category that determines how rigorously it must be assessed.

CUI scope categories

Every system is assigned one scope category. The category reflects how the system relates to CUI, and it drives how deeply an assessor will test it. You can change a category at any time and record a short justification for the choice.

Category	What it means
CUI Asset	Directly stores, processes, or transmits CUI. Assessed against all Level 2 requirements.
Security Protection Asset	Provides security functions that protect CUI Assets (firewall, MFA, SIEM, identity) but doesn't handle CUI itself. Assessed against the requirements relevant to that function.
Contractor Risk Managed Asset	Could technically reach CUI but is kept from doing so by documented policy and practice. Lightly tested if your documentation is solid.
Specialized Asset	OT/ICS, IoT, government-furnished equipment, or test equipment that can't be fully secured with standard IT controls. Reviewed via SSP documentation, not tested against every requirement.
Out of Scope	Cannot reach CUI and provides no protection to systems that do — physically or logically separated. Not assessed, but you must be able to justify the separation.

Categorization is a scoping decision, not busywork. Putting a system in a lighter category (Contractor Risk Managed, Specialized, or Out of Scope) reduces how much you have to prove — but only if you can defend the reasoning. When in doubt, an assessor expects the more rigorous category.

A control objective

CMMC practices break down into objectives — the individual, testable statements an assessor checks (for example, practice AC.L2-3.1.1 decomposes into lettered objectives [a], [b], and so on). You work compliance one objective at a time, and a practice is only "met" when every one of its in-scope objectives is satisfied.

Objective status

Each objective carries a status. It's the single most important field you set.

Status	Meaning
Implemented	Fully satisfied. Counts toward a met control.
Partially implemented	Started but not fully satisfied — counts as a gap, not a pass.
Not implemented	Not yet satisfied. A gap.
Not applicable	Doesn't apply to your environment, with a written justification.
Unassessed	No status set yet — treated as unmet until you record one.

Partially implemented is a failing state. Work that is underway but incomplete does not earn credit toward your score or your assessment — it's counted alongside not-implemented objectives as an open gap. Only a fully Implemented (or justified Not Applicable) objective clears the item.

Evidence health

Beyond pass/fail, each system surfaces the health of its attached evidence: how many pieces have expired and how many are expiring soon (within the next 30 days). Evidence that has lapsed no longer proves anything to an assessor, so these counts flag re-collection work before an audit finds it for you.

Using systems & objectives

The Systems page lists every system with its scope category, its passing / failing objective counts, and its evidence-health indicators at a glance. Open a system to review its objectives, or open any single objective to do the detailed work.

Add a system

Start a new system

From the Systems page, add a system and give it a name and type.

Assign a scope category

Choose the CUI scope category that matches the system's role — CUI Asset, Security Protection Asset, Contractor Risk Managed Asset, a Specialized type, or Out of Scope. Record a short justification for the choice; that reasoning is itself part of your scoping evidence.

Save

The system joins your catalog and immediately appears in your scope summary and objective coverage.

New systems can be seeded from your onboarding answers, so your initial catalog often reflects the environment you described when you first set up your organization. You can refine categories and add or remove systems at any time.

Work an objective

This is the core loop — repeated across every in-scope objective until your assessment is complete.

Open the objective

From a system's objective list (or your assessment), open the objective drawer. It shows the practice text, the specific objective wording, and built-in guidance for what "good" looks like.

Set the status

Mark it Implemented, Partially implemented, Not implemented, or Not applicable.

Write the implementation narrative

In the narrative field, describe how the requirement is met in your environment — the plain-language statement an assessor reads. This same field does double duty: for a Not Applicable objective, you write the justification here, and the N/A status conveys that it's excluded rather than satisfied.

Attach evidence

Link the artifacts that back up your narrative — a policy, a screenshot, a configuration export, an approved evidence request. Evidence attached here flows into your Evidence Library and your SSP.

The narrative isn't optional polish — it becomes the implementation statement in your exported SSP. Writing it well as you go means your SSP is essentially finished by the time your objectives are.

Choose per-system vs shared narratives

Some requirements are satisfied the same way everywhere; others are handled differently on different systems. You control which applies per objective.

Use a shared statement

By default, an objective uses one shared implementation statement that applies across all your in-scope systems. Write it once and it covers every system the objective applies to.

Switch to per-system statements

When a system does things differently, switch that system to an independent statement and write a narrative specific to it. The rest of your systems keep using the shared statement.

Exclude a system from an objective

If a particular objective genuinely doesn't apply to a particular system, you can exclude that system from that objective's scope. Excluded systems drop out of that objective's coverage math, so your counts reflect only the systems the requirement truly touches.

Permissions

Access is governed by the role matrix.

Capability	Permission
View systems, objectives, statuses, narratives, and evidence	VIEW_EVIDENCE
Add / edit systems and set scope categories	MANAGE_SYSTEMS
Set objective status, write narratives, attach evidence	UPLOAD_EVIDENCE

VIEW_EVIDENCE is held by every role, including the read-only Assessor. Recording compliance work (UPLOAD_EVIDENCE) belongs to Org Admin, Org User, MSP Super, and MSP Admin — not the Assessor (read-only) or the Platform Admin. Cataloging and categorizing systems (MANAGE_SYSTEMS) belongs to the org and MSP administrator roles.

The Assessor role is deliberately read-only for compliance data: an assessor can read every system, objective, narrative, and piece of evidence to render a verdict, but cannot change a status or edit a narrative.

How it works

Extra detail on how this work behaves and where it flows — product behavior, not internals.

How a practice becomes "met"

A practice counts as met only when every one of its in-scope objectives is Implemented (or justified as Not Applicable). Any objective that is not-implemented, partially implemented, or still unassessed keeps the whole practice in the failing column. This is why partial progress doesn't move your headline numbers — a practice is all-or-nothing at the objective level.

Why system metrics look the same across systems

Objective statuses are recorded once per assessment, not separately for each system — a status like "Implemented" reflects how you handle that requirement across your environment. Because of that, the passing/failing counts you see on different systems differ only by which objectives each system excludes from its scope. Two systems in the same category with no exclusions will show the same objective math; a system that excludes several objectives (or sits in a lighter category) shows a smaller in-scope set. In other words, the numbers are assessment-wide, filtered per system, not independently tallied per machine.

"Failing" is counted at different grains in different places, and they're not meant to match: a system's failing number counts controls with at least one unsatisfied objective, while an assessment's failing metric counts objectives. In every case, partially implemented is treated as failing — never as a pass.

How this drives your assessment, SPRS, and SSP

The work you do here is the input to three outputs:

Assessment progress

Every status you set advances (or holds back) your assessment's completion and coverage metrics.

SPRS score

Your DoD Supplier Performance Risk System score starts at 110 and subtracts the weighted value of each unmet in-scope control. A control only stops costing you points once all its in-scope objectives are satisfied — so finishing the last objective of a practice is what actually moves the score.

System Security Plan (SSP)

Your implementation narratives — shared and per-system — become the implementation statements in your exported SSP, alongside the systems catalog and its scope categories.

AI assistant access

When the AI Connector is enabled, assistants can read (never change) your systems and objective posture — for example, a rollup of your systems with their passing and failing objective counts. Access follows the same permissions as the app: an assistant only ever sees what the connected user's role is allowed to see.

Assessments

Track completion and coverage across every objective in your CMMC scope.

Evidence Library

Organize, reuse, and monitor the artifacts you attach to objectives.

Asset Inventory

Maintain the detailed inventory of assets behind your systems and scope.

SPRS Score

Your SPRS score is the single number that summarizes CMMC Level 2 readiness. Learn how it's calculated, why controls are weighted, and how to raise it fastest.

Assessment Workbench

Review a single objective in depth — its 800-171A guidance, the implementation narrative, linked evidence, and recorded interviews and tests — in one focused workspace built for internal validation before a formal assessment.