Terms / Scope and assets

Inheritance

Relying on someone else's control to meet a requirement. It is allowed, and you still have to show the control exists and works.

Also called inherited controls, inheriting.

Practitioner Guidance

What it means in practice

Inheritance means another party implements a requirement on your behalf.

Your cloud platform runs the physical security of the data centre. Your identity service enforces multifactor authentication. Your support provider patches the servers. Each of those is a requirement you inherit rather than implement yourself. Inheritance is normal and expected for a small company, and nothing in the program asks you to run everything yourself.

You inherit the control, and you never inherit the responsibility.

The requirement is still yours to satisfy, and your assessment still covers it. That means you name the provider, name the requirement, and hold evidence that the control runs. An assessor asks how you know. The answer cannot be that you assumed the provider handled it.

Evidence for an inherited control comes from the provider, so ask for it early.

A customer responsibility matrix, an authorization package, an audit report, or a configuration export are the usual forms. Ask what the provider will give you before you commit to the service. Providers that serve defense clients will have this ready. Providers that do not will offer a marketing page, which is not evidence.

Partial inheritance is the common case, and it is where companies get caught.

Most requirements split. The provider supplies the capability and you configure it. Multifactor authentication is available, and you decide who must use it and when. Logging is available, and you decide what is collected and who reviews it. Write down which half is yours for each requirement, because the half you forget is the half that fails. CA.L2-3.12.4 is where that split is recorded.

What falls short

A plan that names a provider next to a requirement with no evidence behind it. Naming the provider is a claim, and the assessment tests claims.
Inheriting a control from a provider that never agreed to it. The responsibility matrix is what records agreement.
Treating a certification logo as evidence of a specific control. The requirement is specific, so the evidence has to be too.

Edge cases

Your provider's report covers a different scope from the service you buy. Read what the report covers before you rely on it.
You inherit from a provider that inherits from another. Your evidence still has to reach the control, so ask your provider how it verifies its own supplier.
The provider changes a default and your inherited control quietly changes with it. That is a change worth reviewing, because your scope and your plan describe the old behaviour.

Over-engineering

Implementing a control yourself because inheritance feels risky. Duplicating a provider's control costs money and does not improve the assessment.
Demanding a full audit report from every external service provider. Ask for evidence proportionate to what you are inheriting.

Connects to

Customer responsibility matrix The document from a service provider that says which requirements it meets and which are yours. The rule requires one for every ESP. Scope and assets
CA.L2-3.12.4 System Security Plan Security Assessment (CA)
Scope The set of assets that will be assessed. Scope is the single decision that drives your cost, your evidence burden, and your assessment length. Scope and assets
External service provider An outside provider handling your CUI or your security protection data. What it handles decides how it enters your assessment. Scope and assets

Referenced by

Customer responsibility matrix The document from a service provider that says which requirements it meets and which are yours. The rule requires one for every ESP. Scope and assets
Assessment objective One lettered determination statement inside a requirement. Every applicable objective must be met, or the whole requirement is scored not met. Assessment
NIST SP 800-171A The companion publication holding the assessment objectives. It is the document an assessor actually works from, so it is the one to read. Assessment
Not applicable A finding that a requirement or objective does not apply to your environment. It counts the same as met, and it needs a written reason. Assessment
Policy A short written statement of what your organization requires. It is approved, dated, and it says what people must do, not how. Assessment
FedRAMP The Federal program that authorizes cloud services. A cloud service holding your CUI must meet the FedRAMP Moderate baseline or its equivalent. Certification
FIPS 140 validation A cryptographic module tested and certificated under the NIST validation program. Encryption that is merely strong does not satisfy the requirement. Certification
CM.L2-3.4.5 Access Restrictions for Change Configuration Management (CM)
MP.L2-3.8.9 Protect Backups Media Protection (MP)