--- title: Systems & Objectives description: 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. navigation: icon: i-lucide-server --- # Systems & Objectives **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. ::note 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](#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 | | --- | --- | | :badge[CUI Asset]{color="error"} | Directly stores, processes, or transmits CUI. Assessed against **all** Level 2 requirements. | | :badge[Security Protection Asset]{color="warning"} | 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. | | :badge[Contractor Risk Managed Asset]{color="warning"} | Could technically reach CUI but is kept from doing so by documented policy and practice. Lightly tested if your documentation is solid. | | :badge[Specialized Asset]{color="info"} | 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. | | :badge[Out of Scope]{color="neutral"} | 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. | ::tip 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 | | --- | --- | | :badge[Implemented]{color="success"} | Fully satisfied. Counts toward a met control. | | :badge[Partially implemented]{color="warning"} | Started but not fully satisfied — **counts as a gap**, not a pass. | | :badge[Not implemented]{color="error"} | Not yet satisfied. A gap. | | :badge[Not applicable]{color="neutral"} | Doesn't apply to your environment, with a written justification. | | :badge[Unassessed]{color="neutral"} | No status set yet — treated as unmet until you record one. | ::warning **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 ::steps{level="4"} #### 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. :: ::note 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. ::steps{level="4"} #### 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. :: ::tip 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. ::steps{level="4"} #### 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 | :badge[VIEW_EVIDENCE]{color="neutral"} | | Add / edit systems and set scope categories | :badge[MANAGE_SYSTEMS]{color="info"} | | Set objective status, write narratives, attach evidence | :badge[UPLOAD_EVIDENCE]{color="info"} | `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. ::warning 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. ::note "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: :::field-group ::field{name="Assessment progress"} Every status you set advances (or holds back) your assessment's completion and coverage metrics. :: ::field{name="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. :: ::field{name="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](https://app.dibfi.com/dashboard/org-settings) 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. --- ## Related features :::card-group ::card{title="Assessments" icon="i-lucide-clipboard-check" to="https://app.dibfi.com/dashboard/systems"} Track completion and coverage across every objective in your CMMC scope. :: ::card{title="Evidence Library" icon="i-lucide-folder-open" to="https://app.dibfi.com/dashboard/systems"} Organize, reuse, and monitor the artifacts you attach to objectives. :: ::card{title="Asset Inventory" icon="i-lucide-boxes" to="https://app.dibfi.com/dashboard/inventory"} Maintain the detailed inventory of assets behind your systems and scope. :: :::