List every system and service that touches your in-scope environment. For each one, record the controls it claims to provide for you. Request the provider artifact, such as the CIS/CRM, before your assessment. Split every control into fully inherited, hybrid, or fully yours. Write the customer responsibilities and assign each one an owner and a date. Attach the provider agreement and the artifact version to the SSP. PolicyCortex gives you SSP, SAR, and POA&M output produced from collected evidence, so your inheritance section stays accurate. ( PolicyCortex )

NIST SP 800-18 Rev. 2, Developing Security, Privacy, and C-SCRM Plans for Systems: https://doi.org/10.6028/NIST.SP.800-18r2 NIST SP 800-171 Rev. 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations: https://csrc.nist.gov/pubs/sp/800/171/r2/final

Chapter 1

How Do I Handle Inherited Controls in the SSP?

October 07, 2026

Your systems run on cloud services, yet your System Security Plan (SSP) still needs every control answered.

Controls you borrow from those services are inherited controls.

The National Institute of Standards and Technology (NIST) calls a control shared across many systems a common control.

Your system inherits the protection; the provider implements and owns the details.

A provider that offers shared controls to other systems is called a common control provider.

CMMC, the Cybersecurity Maturity Model Certification, assesses your SSP against NIST SP 800-171 requirements. (NIST SP 800-171 Rev. 2)

The assessor treats borrowed controls the same as controls you implement yourself.

How inheritance works between systems

Inheritance starts with the provider publishing how each control is implemented.

You reference that artifact in your SSP instead of rewriting it.

NIST SP 800-18 allows your SSP to reference inherited common controls instead of restating them. (NIST SP 800-18 Rev. 2)

Implementation details for those controls live in artifacts the provider makes available to you. (NIST SP 800-18 Rev. 2)

For cloud services, ask the provider for its Control Implementation Summary and Customer Responsibility Matrix.

This matrix, called CIS/CRM, splits each control between the provider and you. (NIST SP 800-18 Rev. 2)

Some controls split: the provider covers part, and you cover the rest.

NIST calls these hybrid controls.

For hybrids, state which part each side provides and how risk is shared. (NIST SP 800-18 Rev. 2)

How to document inherited controls in the SSP

Add a dedicated inheritance section to your SSP, right after the system description and boundary.

List each borrowed control once, in this order: provider, requirement, split, artifact, your part, evidence.

First, name the provider and the exact service the inheritance comes from.

Second, name the requirement or control number the inheritance covers.

Third, mark the status: fully inherited or hybrid.

Fourth, point to the provider artifact by name, version, and date.

Fifth, write your customer responsibilities as plain statements, such as reviewing the provider report each quarter.

Sixth, attach your own evidence only for the parts you own.

NIST SP 800-171 requires the SSP to describe system boundaries and the operating environment. (NIST SP 800-171 Rev. 2)

It also requires you to show how each requirement is implemented, including inherited ones. (NIST SP 800-171 Rev. 2)

Keep a signed agreement with each provider that names the controls they cover.

The agreement should state how often the provider updates its artifact.

It should also state how you are told about changes and outages.

Without that agreement, you have no basis to claim inheritance.

Reference your Plan of Action and Milestones (POA&M) for any borrowed control that is not satisfied. (NIST SP 800-18 Rev. 2)

The SSP, the Security Assessment Report (SAR), and the POA&M travel together as your evidence package.

Mistakes that break inheritance claims

The most common mistake is claiming inheritance with no provider artifact.

An assessor will ask for the artifact, and a vendor web page is not one.

Another mistake is double counting: marking a hybrid control fully inherited.

Then nobody owns your half, and the control silently fails.

A third mistake is forgetting customer responsibility statements entirely.

If the matrix assigns you a task, the SSP must say you do it.

A fourth mistake is letting the inheritance section go stale.

Provider services change, so review the section on a defined cycle. (NIST SP 800-171 Rev. 2)

Practical next steps

List every system and service that touches your in-scope environment.
For each one, record the controls it claims to provide for you.
Request the provider artifact, such as the CIS/CRM, before your assessment.
Split every control into fully inherited, hybrid, or fully yours.
Write the customer responsibilities and assign each one an owner and a date.
Attach the provider agreement and the artifact version to the SSP.

PolicyCortex gives you SSP, SAR, and POA&M output produced from collected evidence, so your inheritance section stays accurate. (PolicyCortex)

Sources

NIST SP 800-18 Rev. 2, Developing Security, Privacy, and C-SCRM Plans for Systems: https://doi.org/10.6028/NIST.SP.800-18r2
NIST SP 800-171 Rev. 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations: https://csrc.nist.gov/pubs/sp/800/171/r2/final