RMFInsider

To become a Common Control Provider (CCP), you register the shared capability as its own system in eMASS, select the controls it will provide, implement and document them as if they were being assessed on their own (because they will be), get them assessed by an SCA, and obtain an authorization from an AO. Once the AO signs, the controls are marked as providing inheritance in eMASS and other systems can request them. That is the whole path. The reason it takes a year instead of a month is that every step is done to a higher standard than a single system would need, because the moment you become a provider, every inheriting system’s ATO depends on your evidence holding up.

I have been on both sides of this. As an ISSO inheriting from a data center CCP, the good ones made my package thirty controls lighter and the bad ones made me re-document everything at assessment time because the provider’s evidence had expired. As part of a team building a provider package, I learned that the work is mostly about being boringly consistent for a long time. This post covers which controls make sense to provide, what the CCP package contains, how approval works, and what maintaining it actually requires.

What a Common Control Provider is

DoDI 8510.01 defines the CCP as the organization responsible for the development, implementation, assessment, and monitoring of common controls: security controls whose implementation results in a capability that is inheritable by one or more systems. NIST SP 800-37 Rev 2 uses the same concept and adds that the CCP documents the controls in a security plan, has them assessed by an independent assessor, and reports the results to the systems that inherit. In DoD practice, a CCP is one of a few things:

• An enterprise or component service: a data center, a cloud landing zone, an enterprise identity service, a CSSP providing monitoring, or a network enclave providing boundary protection.
• An installation or facility organization providing physical, environmental, and personnel security to every system in the building.
• A program office hosting several systems on shared infrastructure that decides to authorize the infrastructure once and let the hosted systems inherit.
• A platform team running a DevSecOps pipeline or container platform that provides the build, deployment, and runtime security controls for the applications on it.

The third case is worth considering if you manage three or more systems on the same infrastructure. Writing the same PE, AU, and SC statements three times, and defending them in three assessments, is how you end up with an identical set of findings on every system.

Which controls to provide

A control is a good candidate for common provision when three things are true: one organization implements it once for everyone, that organization can produce the evidence without involving the inheriting systems, and the implementation does not vary by consumer. Controls that meet that test cleanly:

• Physical and Environmental (PE) family: PE-2 through PE-18. Facility access, visitor control, power, fire suppression, temperature. The facility owner provides these to every system inside the walls.
• Personnel Security (PS) family: Position risk designation, screening, termination, transfer, sanctions. Usually provided by the component’s security office and HR.
• Awareness and Training (AT): Annual cyber awareness training and role-based training, when the component runs one program.
• Audit (AU) partially: AU-4 storage capacity, AU-6 review and analysis, AU-9 protection of audit information, and AU-11 retention, when logs are centrally collected. AU-2 and AU-12 (what is logged and by which components) usually stay with the system.
• Boundary protection (SC-7) at the enclave level: The network provider owns the perimeter; systems inside inherit the perimeter but own their internal segmentation.
• Monitoring (SI-4) and incident response (IR-4, IR-5, IR-6) partially: The CSSP provides the sensor grid, the analysis, and the reporting to higher echelons; the system owns detection of application-level events and the local response actions.
• Contingency planning site-level items: CP-6 alternate storage, CP-7 alternate processing site, CP-8 telecommunications, when the data center provides them.
• Media protection (MP) and maintenance (MA) partially: Sanitization services, media destruction, and controlled maintenance when a central shop handles them.

Controls that look shareable but usually are not: AC-2 account management (the system decides who its users are), CM-6 configuration settings (STIGs are applied per component), RA-5 vulnerability scanning (the scanning service may be shared, but the remediation and the results belong to the system), and anything in the IA family below the enterprise identity provider. When a control is genuinely split, document it as a hybrid, with the provider stating its portion and the inheriting system stating the rest. The explanation of control inheritance goes deeper on common versus hybrid versus system-specific.

One test before committing a control to the provider list: can you answer the assessor without calling any inheriting system? If the AU-6 answer is “here is the SIEM, here are the analyst shift logs,” it is common. If it starts with “it depends on the system,” it is hybrid at best.

What the CCP package contains

The provider package is a full authorization package for a system whose function is providing controls. It goes through the same baseline selection and tailoring as any other system, except the selection is driven by which controls you intend to provide rather than by a full CNSSI 1253 baseline. The components:

System registration and boundary

Register the CCP in eMASS as its own system record. Name it for what it provides, not for the organization (a name like “Building 4 Facility Security Controls” ages better than the current directorate’s acronym). The authorization boundary diagram shows the shared infrastructure, the interfaces where inheriting systems connect, and the demarcation between what the provider controls and what it does not. This is the diagram every inheriting ISSO will paste into their own package, so make it accurate.

The provider security plan

An SSP written for the shared capability. It contains the system description, the list of controls provided with a statement for each of whether it is fully common or hybrid, and the control implementation statements for every provided control. The implementation statements are the product here. They should be written so an inheriting ISSO can read them, understand exactly what is covered, and identify what remains theirs. Vague provider statements create vague inheritances, and the assessor of the inheriting system will push the ambiguity back onto the ISSO who had no part in writing it.

Assessment evidence

Every provided control needs evidence at the CCI level in eMASS, the same as a mission system. The SCA assesses the provider directly. Findings become POA&M items on the provider record, and, critically, those findings propagate to every inheriting system’s risk picture. A provider with an open CAT I on PE-3 hands that CAT I to every system in the building.

The inheritance offer

Once the controls are assessed, they are marked in eMASS as available for inheritance. Document alongside the offer: the list of controls offered, the conditions of inheritance (which systems are eligible, physically or logically), the responsibilities that remain with the inheriting system for each hybrid control, the provider’s point of contact, and how the provider will notify inheritors of changes or findings. Some components require this in a formal memorandum from the provider’s AO; check with your SCA before you assume the eMASS flag is enough.

The continuous monitoring strategy

The provider’s continuous monitoring plan has to state how each provided control is re-verified and how often, because inheriting systems will point to it when their own assessor asks whether the inherited controls are still effective. An annual re-assessment schedule for the provided controls, published to inheritors, is the minimum.

How approval works

The CCP needs an authorization decision from an AO. In practice the sequence looks like this:

• The provider organization identifies the controls, builds the package, and submits it to its SCA for assessment. The SCA produces a SAR for the provider record.
• The AO reviews the SAR and issues an authorization. For a facility or enterprise provider, this is often a fixed-term ATO; for a platform provider, it may be placed under ongoing authorization if the monitoring is mature.
• On authorization, the provider marks controls as providing inheritance in eMASS. Only assessed and authorized controls should be offered; offering unassessed controls is a shortcut that fails at the first inheriting system’s assessment.
• Inheriting systems submit inheritance requests in eMASS. The provider reviews each request (is this system actually inside the boundary the provider covers?) and approves or denies. The inheritance walkthrough in eMASS covers the consumer side of that exchange.
• The inheriting system’s AO accepts the inherited controls as part of that system’s authorization. If the provider and consumer have different AOs, reciprocity under DoDI 8510.01 applies: the consuming AO reviews the provider’s authorization rather than re-assessing the controls.

That last point is where CCPs across organizational lines slow down. An AO who has never seen your provider package may want a briefing, a copy of the SAR, and the provider’s POA&M before accepting inheritance. Build that briefing once, keep it current, and offer it before it is asked for.

Maintaining the provider package

This is where the effort actually lives, and it is the part that gets under-resourced because the provider’s own ATO looks fine on the dashboard. The obligations:

• Re-verify provided controls on the published schedule. Update the test results in eMASS so that the control status inheriting systems see reflects the current year, not the authorization year.
• Notify inheritors of every change that affects a provided control. A new badge system, a CSSP transition, a data center migration, or a change in the log retention period all alter what the inheritors are claiming. Send the notice, record who received it, and update the provider SSP.
• Publish findings. When the provider takes a finding on a provided control, every inheriting ISSO needs to know, because their assessor will ask. Silence here is how inheriting systems end up defending a finding they did not know existed.
• Track your inheritors. Keep a current list of every system inheriting from you, with the controls each one takes and the ISSO contact. When your ATO approaches expiration, that list is who you warn.
• Re-authorize before expiration. An expired provider authorization invalidates the inheritance for every consumer. I have watched a facility provider let its ATO lapse and hand twelve systems an unplanned PE family gap on the same day.
• Review the offer annually. Controls you stopped providing must be withdrawn from the offer, with notice, so inheritors can implement them before their next assessment rather than discover the gap during it.

Is it worth becoming a provider?

The math favors it when three or more systems share the infrastructure, or when the shared capability is complex enough that assessing it inside each mission package would be duplicative and inconsistent. It does not favor it for two small systems with one ISSO, where the provider overhead exceeds the savings. The other reason to do it, beyond efficiency, is that a provider package forces the shared infrastructure to be authorized on its own merits, which surfaces gaps that individual systems had been papering over with hopeful implementation statements about the building.

If you are scoping a provider package or an inheriting package and want the artifact list and the control-by-control checks in one working document, the RMF Checklist is what I use to keep both sides of an inheritance relationship assessment-ready.