---
name: ssp-capability-seed-list
description: The canonical 15-Capability seed taxonomy for the SSP system, with NIST 800-53 family / FedRAMP 20x KSI family / CMMC L2 domain alignment, starter Component mapping guidance, cross-cutting Component rules, allowed per-tenant extensions, and anti-patterns. Load when proposing which Capability a Component rolls up under, organizing SSP §9 narrative, or disambiguating multi-purpose evidence.
---

# SSP Capability seed list

## References

| Reference | Type | Location | When to Use |
|---|---|---|---|
| `halo-ssp-asset-model` | Skill | `plugins/grcitsm-analyst/skills/halo-ssp-asset-model/` | Capability dtype 178 / Component dtype 173 / relationship rel 6 schema |
| `halo-ssp-asset-write-conventions` | Skill | `plugins/grcitsm-analyst/skills/halo-ssp-asset-write-conventions/` | Capability AFUUID convention + framework-CF rollup rules |
| `ssp-ingest` | Skill | `plugins/grcitsm-analyst/skills/ssp-ingest/` | Proposed-New-Capability staging path for per-tenant extensions |
| `grcitsm` | Skill | `plugins/grcitsm-analyst/skills/grcitsm/` | Asset-side workflow (create_asset → update_asset chain) |
| `ssp-spine-reference.md` | File | `reference-docs/ssp-spine-reference.md` | Reconcile pattern that materializes Capabilities per Site |

## Summary

This page is the canonical list of **15 Capabilities** that the SSP system uses as its seeded taxonomy. Every new tenant starts here; tenants extend per-tenant via the `Proposed New Capability` staging path in `/ssp-ingest`. The list is functional (how the system actually works), not control-family-mirrored (NIST 800-53 AC/AU/CM/IA/etc.) — a Capability typically owns implementations across multiple control families.

Naming uses industry-standard NIST 800-53 family / NIST CSF 2.0 / CMMC L2 domain terms, framework-agnostic across CMMC, FedRAMP Rev5, and FedRAMP 20x.

Use this when:
- `/ssp-ingest` proposes which Capability a newly-extracted Component should roll up under.
- `/ssp-generate` walks Capabilities at §9 (System Environment) to organize the implementation narrative.
- An agent needs to disambiguate "this evidence is about IAM" vs "this evidence is about Endpoint Protection" when the Component itself is multi-purpose (e.g. Defender XDR straddles Endpoint + Logging).

Pair with [[halo-ssp-asset-model]] for the underlying asset schema and [[halo-ssp-asset-write-conventions]] for how Capabilities and their Component rollups actually get written to Halo.

## The 15

Stored in Halo's `CTCapabilities` custom table (standard GRCITSM tenant schema) with columns `CFCapabilityAcronym` (slug) + `CFCapabilityTitle` (full name). AFUUID convention on per-Site Capability assets: `CAP-{SystemID}-{Acronym}` (e.g. `CAP-ACME-IAM`).

| # | Slug | Capability | NIST 800-53 family | 2026 KSI family | CMMC L2 domain |
|---|---|---|---|---|---|
| 1 | `IAM` | **Identity and Access Management** | AC, IA | IAM | AC, IA |
| 2 | `MLA` | **Monitoring, Logging, and Auditing** | AU, SI (partial) | MLA | AU |
| 3 | `CRYP` | **Cryptography and Key Management** | SC-12/13/28, MP | SVC (ASM, VCM partial) | MP, SC partial |
| 4 | `NBP` | **Network and Boundary Protection** | SC (boundary), AC-17/20 | CNA, SVC (SNT) | SC |
| 5 | `EP` | **Endpoint Protection** | SI (malicious code), CM (endpoint config) | CNA, SVC (VRI partial) | SI |
| 6 | `IR` | **Incident Response** | IR | INR | IR |
| 7 | `BR` | **Backup and Recovery** | CP | RPL | (not a CMMC L2 domain explicitly) |
| 8 | `CM` | **Configuration and Change Management** | CM, MA | CMT | CM, MA |
| 9 | `VM` | **Vulnerability Management** | RA-05, SI-02/04 | (FRR-VDR rule in 2026) | RA partial, SI partial |
| 10 | `AT` | **Cybersecurity Awareness and Training** | AT | CED | AT |
| 11 | `SCRM` | **Supply Chain Risk Management** | SR + SA-9 | SCR | (CMMC L3 adds supply chain) |
| 12 | `GRM` | **Governance and Risk Management** | PM, PL, RA (org-level), PS partial, PT, SA-4/5 | PIY (policy + executive + investment + inventory) | RA, PS partial |
| 13 | `SDLC` | **Software Development Life Cycle** | SA-3, SA-8, SA-10, SA-11, SA-15, SA-17 (developer-side) | PIY-RSD (Reviewing Security in SDLC), CNA partial | (CMMC L3 partial — secure dev) |
| 14 | `PE` | **Physical and Environmental Protection** | PE | (none — 20x is cloud-native) | PE |
| 15 | `CMA` | **Continuous Monitoring and Authorization** | CA, PT | (FRR-CCM rule in 2026) | CA |

### Naming notes

- **`SCRM`**: the 2026 KSI family is `SCR` "Supply Chain Risk"; "SCRM" is the NIST SP 800-161r1 standard term.
- **`GRM`**: captures NIST PM (Program Management) + PL (Planning) + org-level RA + PT + acquisition-related SA-4/5; KSI-PIY covers the policy/executive/investment review aspects. Kept separate from SDLC — mixing governance, policy, and developer-side SDLC in one Capability is a maintenance burden.
- **`SDLC`**: explicitly the developer-side SA controls (SA-3 SDLC, SA-8 engineering principles, SA-10 dev config mgmt, SA-11 dev testing, SA-15 dev process, SA-17 dev security architecture). Validated by `KSI-PIY-RSD` "Reviewing Security in the SDLC."
- **`MLA`**: matches the KSI family code exactly ("Monitoring, Logging, and Auditing").
- **`PE`**: Rev5 + CMMC only; 20x has no PE family because cloud-native systems delegate physical to the underlying CSP.

### Considered and rejected gaps

| Potential addition | Verdict |
|---|---|
| **Personnel Security** (NIST PS, CMMC L2 PS domain — 2 practices) | Folded under `CAP-GRM` (HR governance) + `CAP-IAM` (joiner/leaver). Add as standalone `CAP-PS` if CMMC L2 strict-domain coverage matters. |
| **Maintenance** (NIST MA, CMMC L2 MA domain — 6 practices) | Folded under `CAP-CM` (config includes maintenance) + `CAP-VM` (patching). Add `CAP-MA` if CMMC L2 strict-domain coverage matters. |
| **Media Protection** (NIST MP) | Covered by `CAP-CRYP` (data-at-rest) + `CAP-CM` (data lifecycle). |
| **Asset Inventory Management** (KSI-PIY-GIV, NIST CM-08) | Folded under `CAP-CM` per NIST conventions (config includes inventory). |
| **Privacy** (NIST PT) | Folded under `CAP-GRM` unless system carries explicit PII workloads warranting a standalone Capability. |

### Reconcile-pattern integration

The 15 Capabilities are materialized per-Site by the SSP spine reconcile pattern (see `reference-docs/ssp-spine-reference.md`): the spec cross-joins active SSP Sites (those with non-empty `Site.CFBaselines`) against `CTCapabilities` and diff-creates missing Capability rows. AFUUID convention: `CAP-{SystemID}-{Acronym}`.

## Example Component → Capability mappings

A typical Microsoft-cloud + MDR stack, sorted into the seeded Capabilities. On a first `/ssp-ingest` run against a tenant whose existing Components have no upstream Capability links, stage a mapping like this for user approval:

| Component | Component Type | CMMC Asset Type | Provider | Proposed Capability |
|---|---|---|---|---|
| Entra ID | Service | SPA | Microsoft | Identity and Access Management |
| Privileged Identity Management | Service | SPA | Microsoft | Identity and Access Management |
| Huntress ITDR | Service | SPA | Huntress | Identity and Access Management |
| Defender XDR | Service | SPA | Microsoft | Endpoint Protection |
| Intune | Service | SPA | Microsoft | Endpoint Protection |
| Cloud PC | Service | CUI | Microsoft | Endpoint Protection |
| Huntress MDR | Service | SPA | Huntress | Endpoint Protection |
| Remote Browser Isolation | Service | SPA | Cloudflare | Endpoint Protection |
| Huntress SIEM | Service | SPA | Huntress | Monitoring, Logging, and Auditing |
| Purview | Service | SPA | Microsoft | Monitoring, Logging, and Auditing |
| Huntress SAT | Service | SPA | Huntress | Cybersecurity Awareness and Training |
| Incident Response Plan | Plan | SPD | (in-house) | Incident Response |
| Information Security Policy and Procedures | Document | SPD | (in-house) | Configuration and Change Management *(governance scope — see note)* |
| System Security Plan (SSP) | Plan | SPD | (in-house) | Configuration and Change Management *(SSP-as-document — see note)* |
| SharePoint | Service | CUI | Microsoft | *(cross-cutting — see note)* |
| OneDrive | Service | CUI | Microsoft | *(cross-cutting — see note)* |
| Exchange | Service | CUI | Microsoft | *(cross-cutting — see note)* |
| Teams | Service | CUI | Microsoft | *(cross-cutting — see note)* |
| ITSM platform | Service | SPD | (vendor) | *(cross-cutting — see note)* |
| Automation platform (e.g. n8n) | Service | SPA | (vendor) | *(cross-cutting — see note)* |

### Cross-cutting Component note

A Capability links **one-to-many** to Components (`Capability Has Components`), but the Halo allow-list doesn't restrict a Component to a single upstream Capability — multiple Capabilities can claim the same Component. For cross-cutting tools (SharePoint, OneDrive, Exchange, Teams, ITSM/automation platforms), the recommended pattern is:

- **Pick one *primary* Capability** for the Component's main implementation lens (e.g. SharePoint → `Configuration and Change Management` if its role is governance-doc storage; → `Identity and Access Management` if its role is access-controlled collaboration; → no parent if it's purely a CUI data store with no implementation responsibility).
- **Do not multi-parent on first ingest.** Multi-parent only when the tenant's evidence clearly demonstrates two separate Capability stories for the same Component. Otherwise multi-parenting blurs Capability ownership and makes §9 of the generated SSP read confusingly.

The decision on cross-cutting Components is **deliberately staged for tenant input** at first `/ssp-ingest` rather than baked in here.

### Governance-document Components

Policy/procedure documents and the SSP itself are Components of type `Document` / `Plan` — they don't implement controls directly, they ARE the documentation. Two reasonable placements:

1. **Under `Configuration and Change Management`** — treating policy/procedure documents as part of the system's documented configuration baseline. Aligns with CMMC's SPD (System Protection Documentation) categorization that these Components carry.
2. **Floating (no Capability parent)** — keep them in the asset graph but unparented, because they cover every Capability and parenting them under one feels arbitrary.

Default to option 1 (Configuration and Change Management) on first ingest; the tenant can override.

## Allowed extensions per tenant

Tenants may add Capabilities via the `/ssp-ingest` "Proposed New Capability" staging path when evidence describes a functional area not in the 15. Common tenant-specific additions seen in adjacent engagements (NOT seeded by default):

- **Continuous Compliance Automation / ConMon Data Sharing** — when the tenant's compliance automation tooling is a first-class implementation surface rather than a leveraged authorization. Typically covers FedRAMP Rev5 CA-2/5/6/7/(01) plus the FRR.CCM Collaborative Continuous Monitoring, FRD-PFA Persistent FedRAMP Assessment, FRR.CDS Trust Center, and FRR.FRC certification-lifecycle machinery. (The seeded `CAP-CMA` already covers the CA-family core; extend only when the automation pipeline itself needs its own implementation story.)
- **Data Loss Prevention** — when DLP is a distinct program from Endpoint Protection and Monitoring/Logging.
- **Privacy Engineering** — when privacy controls (PIA, consent management, data subject access) are managed separately from security controls.
- **Threat Intelligence** — when a dedicated TI program feeds the SOC rather than being embedded in Monitoring, Logging, and Auditing.
- **Build & Release Security** — when CI/CD security (SAST, DAST in-pipeline, dependency scanning, artifact signing) is a distinct program from Vulnerability Management and SDLC.

The seed list is intentionally conservative. Resist seeding tenant-specific entries here; let evidence justify them per-tenant.

## Anti-patterns

1. **Mapping a Capability 1:1 to a NIST 800-53 control family.** Capabilities are functional groupings *across* control families (IAM covers AC + IA; Monitoring/Logging covers AU + parts of CA + SI). A 1:1 mapping was explicitly rejected during the seed-list design.
2. **Creating a Capability per Component.** Capabilities are coarser than Components. A tenant with 30 Components should still have ~15 Capabilities, not 30.
3. **Creating a Capability per control family the IRs are tagged with.** The IR's framework-CF attribution lives at the IR row — Capabilities don't need their own per-family rollup.
4. **Parenting synthetic test Components under any Capability.** Leave them unparented or retire them.

## Cross-references

- [[halo-ssp-asset-model]] — the underlying asset schema (Capability dtype 178, Component dtype 173, relationship rel 6).
- [[halo-ssp-asset-write-conventions]] — how Capability writes happen (read-merge-write, framework-CF rollup rules).
- [[ssp-ingest]] — the Proposed-New-Capability staging path.
- [[grcitsm]] § Asset-side workflow — create_asset → update_asset chain.
- `reference-docs/ssp-spine-reference.md` — the reconcile pattern that materializes Capabilities per Site.
