Common Control Provider (CCP) Role Course — RMF Coach

Lesson 1 — What the CCP Provides (~8 min)

You build a control once so dozens of systems never have to.

Define the Common Control Provider: the party that implements controls once for many systems to inherit.

You run the agency's shared services — the facility that hosts systems, the identity service that authenticates their users, parts of incident response. Dozens of systems, including the Harbor Benefits System, don't build these themselves; they inherit them from you. You are the Common Control Provider (CCP).

A common control is a control implemented once by a provider and inherited by many systems. Your mandate is to implement and run those shared controls so that each inheriting system can point to you instead of rebuilding the same protection. When Marcus stands up Harbor, he doesn't re-implement facility protection — he inherits yours, documents the inheritance, and focuses his effort on Harbor-specific controls.

That's the job: provide protection at scale. Your leverage is enormous — one well-run identity service secures dozens of systems. So is your responsibility: a weakness in your common control is a weakness inherited by every system that relies on it. This course teaches you to provide common controls that systems can safely build on.

The defining feature of the CCP role is the multiplier. A system owner's good control protects one system; your good common control protects every system that inherits it. That cuts both ways, and holding both sides in mind is the heart of the job.

On the upside, you're the highest-leverage security role in the portfolio. Harden your identity service and dozens of systems get stronger authentication overnight, with no work on their part. Standardize incident response once and every inheritor gets a vetted capability. This is why organizations invest in common control providers — it's the most efficient way to raise security broadly.

The downside is the same fact inverted: a failure in your common control is inherited by all of them simultaneously. If your identity service has a flaw, it's not one system's problem — it's a flaw in dozens of systems at once, most of whose owners don't even know it's there because they (correctly) trusted you. That concentration of risk is the weight the CCP carries, and respecting it — never treating a common control casually — is what separates a provider systems can build on from one that quietly endangers them all.

Lesson 2 — The Inheritance Contract (~8 min)

Inheriting systems rely on you — be explicit about what you provide.

Describe the inheritance relationship and what the CCP owes the systems that inherit.

Inheritance is a kind of contract, even when it's informal, and your job is to make it explicit. An inheriting system is trusting that your common control does what it claims — so you owe them a clear statement of exactly what you provide, how it's implemented, and crucially, what they still have to do themselves.

The danger is the gap. If Harbor assumes your identity service handles all of authentication, but your common control actually covers only the central directory and leaves application-level session management to each system, then there's a hole nobody owns — Marcus thinks you've got it, you think he's got it, and an attacker walks through the middle. Explicit inheritance contracts close that gap: "we provide X and Y; you are responsible for Z."

So a good CCP publishes, for each common control, a clear inheritance statement: what's covered, the evidence inheritors can cite, and the residual responsibility that stays with the system. That clarity is what lets a system owner inherit confidently and an assessor verify the boundary between your control and theirs. Inheritance without a clear contract isn't a gift; it's a shared liability waiting to surface.

Not every control is cleanly all-yours or all-theirs. Many are hybrid controls — part common (provided by you) and part system-specific (completed by the inheritor). Recognizing and defining the split is core CCP craft.

Take awareness training. You might provide the organization-wide training program and platform (the common part), while each system is responsible for ensuring its people actually complete it and for any system-specific training (the system part). Or logging: you provide the central log infrastructure and retention; each system configures what it sends. The control only works if both halves are done — and the split must be explicit, or the seam becomes the gap.

For you, hybrids are where inheritance gets subtle. A purely common control is easy to communicate; a hybrid requires you to draw the line precisely: "we provide the platform and retention; you are responsible for configuring sources and reviewing alerts." Get the line clear and inheritors know exactly where your responsibility ends and theirs begins. Leave it fuzzy and you get the worst outcome — both sides assuming the other covered the overlap.

Lesson 3 — Common Control Authorization (~7 min)

Your common controls get authorized too — and inheritors lean on that.

Explain common control authorization and how it underpins inheritance.

Your common controls don't escape the RMF — they get authorized too, through a common control authorization. An AO (Karen) reviews the security of your shared controls — their plan, their independent assessment, their open items — and authorizes them for use, exactly as an AO authorizes a system. Control CA-6 covers this.

Why does this matter to inheritors? Because when Harbor inherits your identity service, it's leaning not just on the control but on its authorization. The strength of Harbor's inherited protection is backed by the fact that an AO independently reviewed and authorized your common control. That authorization is part of what makes inheritance trustworthy rather than a leap of faith.

Which gives you a duty inheritors can't see: keep your authorization current and in good standing. If your common control authorization lapses or is weakened, every system inheriting from you is affected — they may suddenly be relying on a control whose authorization no longer holds. So you treat your authorization not as your own paperwork but as a shared asset that dozens of systems are quietly standing on. Module 2 is how you build and sustain common controls worthy of that trust.

Lesson 1 — Identify & Scope Common Controls (~7 min)

Not everything can be common — pick what genuinely serves many systems.

Identify which controls can be provided as common and scope them appropriately.

The first CCP judgment is what should be common. The best candidates are controls that are uniform across many systems and benefit from central provision: facility and environmental protection, identity and authentication services, network boundary protection, incident response, security training, audit infrastructure. These are the same for every system, so building them once is pure win.

The trap is forcing a control to be common when systems genuinely need it differently. If two inheriting systems have materially different requirements for a control, a one-size common control either over-serves one and under-serves the other, or papers over the difference. In those cases the honest answer is a hybrid (provide the common part, leave the variable part to the system) or letting it be system-specific. Don't make something common just to grow your footprint.

Done as part of the RMF Prepare step (often with the security architect and risk executive), this scoping shapes the whole inheritance model: a clean set of well-chosen common controls that genuinely fit their inheritors, with hybrids where the fit is partial. Choosing well here is what makes the rest of your job — documenting, assessing, sustaining — tractable and honest.

Lesson 2 — Document for Inheritance (~7 min)

Your documentation is what every inheritor cites — make it solid.

Document common controls so inheriting systems can rely on and cite them accurately.

Your common controls live in a plan of their own (a common control / provider SSP, per PL-2), and that documentation has an unusual property: it's cited by everyone who inherits. When Harbor's SSP says "facility protection: inherited from shared services," it's pointing at your documentation. So your docs aren't just yours — they're a dependency in dozens of system packages.

That raises the bar in two ways. Your documentation must be accurate (it describes what's really implemented, because assessors will test your controls against it just like any system's) and inheritance-ready (it clearly states what an inheriting system can claim, the evidence they can cite, and the residual responsibility that stays with them). A vague or stale common-control description doesn't fail one system — it weakens every package built on it.

Think of it as writing an interface that many systems program against. The cleaner and more precise your common-control documentation, the more confidently inheritors can build on it and the more smoothly their assessments go. Sloppy provider docs ripple outward into dozens of confused, gap-prone inheritances. Precision here is a gift to your whole portfolio.

Lesson 3 — Get Your Controls Assessed (~7 min)

Your common controls are assessed once, and many inherit the result.

Support independent assessment of common controls so inheritors can rely on the result.

Your common controls get independently assessed (CA-2) just like a system's, and the efficiency is the whole point: assessed once, the result is inherited by every system that uses them. When Priya tests your identity service and finds it satisfied, dozens of systems can cite that finding instead of each re-testing identity. That's the do-once-use-many leverage on the assessment side.

Your role is the same support discipline any owner brings — give the assessor access and evidence, answer honestly, don't steer — but with amplified stakes. A clean, well-evidenced assessment of your common controls is a gift to your whole portfolio; a rough one (or one with thin evidence) drags down every package that inherits it. So you prepare for your assessment knowing many systems are riding on the result.

There's a subtlety inheritors depend on: the assessment must cover what you actually provide, at the right rigor. If your common control serves Moderate systems, it's assessed to that bar, and inheritors can rely on it for Moderate. An inheriting High system may need more than your Moderate common control provides — which your inheritance documentation should make clear. Getting your common controls assessed well, and scoped honestly, is what lets inheritance be a genuine shortcut rather than a hidden shortfall.

Lesson 4 — Concentration Risk (~8 min)

Your single point of strength is also a single point of failure.

Recognize and manage the concentration risk that common controls create.

The flip side of your leverage is concentration risk. Because so many systems inherit your common control, it becomes a single point of failure for all of them at once. If your identity service goes down or is compromised, it's not one outage — it's an authentication failure across every inheriting system simultaneously.

This changes how you must run common controls versus a one-system control. The blast radius of any failure is your whole portfolio, so common controls deserve disproportionate hardening, redundancy, and monitoring. A control that would be "good enough" for one low-traffic system isn't good enough when dozens of systems' security depends on it. You invest more, precisely because the failure is multiplied.

It also shapes prioritization. When you weigh where to spend effort, remember that improving a common control improves the whole portfolio, and a weakness in one endangers the whole portfolio — so your common controls should generally sit above the security bar of the systems that inherit them, not at it. Respecting concentration risk — treating your shared controls as the critical infrastructure they are — is what makes inheritance safe instead of a hidden, portfolio-wide fragility.

Sam's shared identity service authenticates users for thirty systems, including Harbor. A proposal lands: add phishing-resistant MFA and a redundant, geographically-separated instance. It's expensive, and for any single small system the upgrade would be hard to justify on its own.

But Sam does the concentration math. This isn't one system's authentication — it's the front door for thirty. An outage takes all thirty offline; a compromise exposes all thirty at once. Measured against that blast radius, the upgrade is obviously worth it: the cost is shared across thirty systems' worth of risk reduction, and the failure it prevents would be a portfolio-wide catastrophe, not a single-system incident. Sam funds it, and updates the inheritance documentation so every inheritor knows their authentication just got stronger (and can cite the improved control).

That's the CCP's defining judgment: evaluate common controls against the blast radius, not a single system. A control protecting thirty systems should be hardened like critical infrastructure, because that's exactly what it is. The same upgrade that's marginal for one system is essential for a common control — and seeing that clearly is what separates a CCP who strengthens the portfolio from one who quietly concentrates its fragility. Your turn — three provider calls.

Lesson 1 — Monitor & Report to Inheritors (~7 min)

Inheritors can't see your controls — your reporting is their only window.

Continuously monitor common controls and report their status to inheriting systems.

You run continuous monitoring (CA-7) on your common controls like any owner — but you have an extra duty no single-system owner has: reporting status to your inheritors. The systems inheriting your controls cannot see them; they're trusting controls that live in your boundary. Your monitoring reports are their only window into the health of protections they depend on.

So a good CCP doesn't monitor in private. You publish the status of your common controls — are they operating, any incidents, any degradations — to the systems that inherit them, so each inheritor's ISSO and owner can factor your controls' real state into their risk picture. If your identity service has a degradation, Harbor's ISSO needs to know, because it affects Harbor's posture even though Harbor didn't cause it and can't fix it.

This is the monitoring counterpart to the inheritance contract: you committed to provide certain protections, and reporting is how you continuously prove you're still providing them. An inheritor who hears nothing from their CCP is flying blind on a chunk of their own security. Transparent, regular reporting is what lets inheritance remain trustworthy after day one.

Lesson 2 — Keep the Authorization Current (~6 min)

A lapsed common-control authorization quietly undermines every inheritor.

Maintain the common control authorization in good standing so inheritance stays valid.

Your common control authorization isn't a one-time milestone — it's a standing condition that inheritance depends on, and keeping it current is core CCP work. Through ongoing authorization and timely reauthorization when warranted, you keep your shared controls in good standing under CA-6.

The failure mode is quiet and dangerous. If your common control authorization lapses — it expires, or a significant change invalidates it and you don't address it — then every system inheriting from you is suddenly relying on controls whose authorization no longer holds. The inheritors usually have no idea; their packages still say "inherited from shared services," pointing at an authorization that's gone stale. You've created a portfolio-wide gap that's invisible from inside any single system.

So you manage your authorization like the shared infrastructure it is: track its status, keep ahead of expiration, and when a significant change hits your common controls, drive the reauthorization before the old basis lapses. A CCP who lets their authorization slide doesn't fail alone — they pull the rug out from under every system that trusted them. Keeping it current is how you honor the dozens of inheritances standing on it.

Lesson 3 — Communicate Change to Inheritors (~6 min)

When you change a common control, you change every system that inherits it.

Communicate changes to common controls to all inheriting systems.

When you change a common control, you're not changing your system — you're changing everyone's. A modification to your identity service, a new configuration on the shared firewall, a change to the incident-response process propagates instantly to every system that inherits it, whether their owners know or not. So communicating change to inheritors is a duty unique to the provider.

The risks run both ways. A change that strengthens a common control is good news inheritors should be able to cite (their posture just improved). A change that weakens or alters it — or rises to a significant change affecting the common controls' authorization — is something inheritors must know, because it changes their risk picture and may require action on their side (or reauthorization of the common controls that flows down to them). Either way, silence is the enemy: an inheritor surprised by a change to a control they depend on can't manage what they didn't know changed.

So a mature CCP runs change communication as a standing practice: notify inheritors of material changes, update the inheritance documentation, and flag anything significant. You're the hub of a hub-and-spoke dependency, and keeping the spokes informed is what keeps the whole inheritance model honest as your shared controls evolve.

Lesson 4 — You Are the CCP (~11 min)

A hybrid split, a common-control failure, a lapsing authorization — all yours.

Make and defend the provider decisions a CCP owns, with consequences.

A new inheriting team asks Sam: "Your shared logging service covers audit logging for us, right? We'll just inherit it." It's tempting to say "yep, we've got it" and move on. Sam doesn't.

Because logging is really a hybrid. Sam's service provides the central log infrastructure, retention, and protection of the logs — but it can't know what events each system should generate, and it doesn't review each system's alerts. If Sam just says "we've got it," the new team will assume audit logging is fully handled, never configure their event sources or review their alerts, and a whole half of the control silently won't exist. The seam becomes the gap.

So Sam draws the line explicitly: "We provide the log infrastructure, 12-month retention, and log protection — you inherit those and can cite our assessment. You are responsible for configuring which events your system logs and for reviewing your alerts. That's the hybrid split." He updates the inheritance documentation to say exactly that. Now the new team inherits the common part confidently and knows precisely what they still owe. That's the CCP's craft: make the seam explicit so nothing falls through it. Your turn — three provider calls.

The whole role in one breath. You provide controls once that many systems inherit — the highest-leverage security role in the portfolio, and the one carrying the most concentrated risk. You make inheritance an explicit contract (what you cover, what stays with the system), define hybrid splits cleanly, and get your common controls authorized (CA-6) and independently assessed (CA-2) so inheritors can rely on them.

You respect concentration risk — hardening shared controls above the bar because their failure hits everyone — and you sustain the service: monitor and report status to inheritors who can't see your controls, keep your authorization current so inheritance stays valid, and communicate change to every inheriting system.

Through all of it, the CCP's discipline is the same: everything you do is multiplied by your inheritors. A clear contract, a hardened control, a current authorization, an honest status report — each one lifts the whole portfolio; each lapse endangers it. Hold that and you're the provider systems can safely build on. The scenario below drops you into three provider calls — decide, and see the consequences.