One control, many plans
Most of the controls in a typical security plan are not implemented by the team that owns the plan. Sign-in, logging, backup and the data center are run by someone else, for everyone.
In Federated Cyber Risk (FCR), each of those shared capabilities is a common control service: a service that implements controls on behalf of the teams that use it.
Treating these services as a formal part of the program is what lets a control be examined once instead of once per plan. Whether that works depends on what the provider documents, who checks it, and what happens when it changes.
The plan and the inventory are different documents
Many common control services already have a security plan. That plan describes how the service itself is protected.
It does not answer the question a customer brings: which controls does this service implement for me? FCR adds a second document for that, the service's control inventory. The inventory describes what the service delivers to its customers, control by control.
The two are easy to confuse, and they serve different readers. The plan is for whoever is accountable for the service. The inventory is for everyone who depends on it.
What a provider writes down
A provider's inventory covers four things:
- The service as it is offered today. The inventory describes current services, not plans or history.
- The controls it implements for its customers. These are the controls a team can inherit by using the service.
- Enough implementation detail for a customer to answer an auditor. A team asked how an inherited control works should not have to phone the provider.
- How a team can tell whether it uses the service. Inheritance only works if consumers can recognize themselves.
Providers own their inventories, because nobody else knows the service as well or hears about changes as early. Where a provider can't take that on yet, the security office can hold an inventory as a stopgap, with the intent of handing it back.
Verification with an expiry date
An inventory is a provider's claim. Before others build on it, the security office reviews the controls and checks that the evidence behind them is sufficient.
A service that passes is marked as verified, by a named reviewer, for a limited period. The limit matters. A verification with no end date slowly becomes a statement about the past, so it expires and has to be earned again against current evidence.
The review also identifies the responsibilities the service leaves with its customers. Those are recorded too, so a team inheriting a control can see what remains theirs.
How a team inherits
A resource team does not study inventories. It answers a short assessment that identifies which common control services it uses.
The controls those services deliver are then inherited into the team's plan by reference. Questions the services already answer are answered for the team.
What is left is the team's own part: the controls no service covers, and the customer responsibilities that came with the ones it inherited. A team that runs something itself adds its own controls alongside the inherited ones.
When the service changes
Providers update their inventories as part of change control, so recording a change is part of making it.
An updated inventory does two things. Every plan that inherits from it is flagged, which is the subject of D&D: Dependency Trees and Drift. And the service's verification goes on a clock: it holds for a grace period while the security office re-verifies against the new inventory, and it lapses if that doesn't happen.
A service is documented and verified once. From then on it cycles: teams inherit, the service changes, the change reaches every dependent plan, and the service is verified again.
The case automation can't see is a control that lapses while the inventory stays the same. Ownership under change control makes that less likely, and expiring verification catches what slips through.
Where to start
No organization documents every shared service at once. Start with the services the most teams use, because each one verified removes the same question from the largest number of plans.
Each verified service becomes a building block. Once it exists, every plan that uses it gets more accurate, with no extra work from the team that owns the plan.