In most organizations you are constantly upgrading your security controls. This is for many reasons, including:
New threats induce higher risk exposure and require new forms of mitigation
New assets or business processes change the risk profile requiring better controls
Old controls, or wider mitigation frameworks, may have newly discovered flaws
Current controls might be harming organization agility or efficiency in the context of business goals
New legal, regulatory or contractual requirements stipulate a new form of control
So, if you have a risk informed security program, you are going to be constantly upgrading controls. How do you prioritize the upgrades and how do you bring transparency to that?
First, you need a decent asset inventory and from that some unit of measure. If you haven't got a such an inventory then that's job 1, but you can make progress even with any form of inventory, for example: a list of all your organization's business applications. Your unit of measure could be multiple, but often it is most practical to think of an application as a unit - with some additional ones for critical infrastructure components, groups of infrastructure products/services or aggregations of data.
Then, you need some method of criticality ordering those assets, this could be across multiple dimensions, for example: nature of the data, legal/regulatory stipulation, importance of the supported business services, contractual requirements, and so on. Finally, you need to know how up to date things are and have visibility into the active projects that are building new things.
PRINCIPLE 1 : When you are upgrading controls you want to focus on the Most Critical assets and all the assets (application, systems, etc.) that are being built anew or being upgraded anyway. This, irrespective of criticality, is useful because some of those systems will become critical over time and it will save you the control integration effort in the future. It is also important because the more you scale your controls as a set of platforms for broader use the more cost-effective and efficient they will become (raise the baseline by reducing the cost of control).
From this you can draw a simple diagram to visualize where your focus should be:
Then, and this is where the excess simplicity of this works in your favor, you can start tracking and reporting to whatever Board, management or other governance apparatus you have or have constructed:
Of course, there will likely be more granular detail beneath this to map to particular control platforms/upgrade cycles. But you need to be able to answer, in simple terms, what percentage of new things being built have built-in the new control set.
PRINCIPLE 2 : Work to reduce the amount of The Rest. This could be done by a program of preventative maintenance, upgrades or application refactoring that when done picks up the newest controls, or it could be (and this will vary by organization type) that over time more of your environment becomes more critical or you can afford to designate it as such because you have provided cheaper and more efficient platforms to deliver your core controls. These control platforms should be progressively easier to integrate and use by your development teams (or end users). Again, this is the notion of raise the baseline by reducing the cost of control.
Then you can track this reduction:
To ultimately get to a better state:
Of course, you are going to constantly need to play catch-up. The world and your environment is not static and so these metrics will fluctuate as you add new control requirements - even the most recent assets will need control improvements or other upgrades - but if you are constantly optimizing your controls as platforms then this should be progressively easier. If not, then you'll see excess fluctuation or stagnancy in your metrics.
COROLLARY : The percentage of your assets defined as critical will increase over time. It can be counter-intuitive to think of a growing share of your environment being Most Critical so perhaps a better designation is simply Critical. The point being that as a you consolidate your environment onto a small set of applications/platforms you are inherently going to have a higher percentage of those become more critical for you. More of your environment becoming more important to you is a sign you are doing this right - but you do need to highly assure the control and resilience levels of that and architect those platforms to reduce their unit blast radius.
Bottom line: don't just focus control upgrades on your most critical assets, focus also on your newest ones. This will not only ensure that systems that become more critical over time are inherently protected but, more importantly, will help assure the control platforms you deploy will scale and be more cost effective, efficient and easy to use. Raise the baseline by reducing the cost of control is a good flywheel to jump start.