Understanding the Control Maturity Score Calculation#

What is Control Maturity?#

Control maturity measures how consistently, reliably, and formally a control is designed and executed. Maturity scores measure the operational consistency and formalisation of your controls. A higher score reflects greater confidence that the control will perform as intended, helping to demonstrate both the effectiveness of your risk mitigation and your adherence to regulatory compliance frameworks.

Control Maturity scores are always provided on a 0-5 scale and the specific labels may vary from framework to framework, but the Cydea default scoring that will be applied when a framework does not have its own defined maturity scoring is as follows:

0. Not Achieved: Practices are absent, incomplete, or entirely neglected. The organisation has no systematic processes in place to manage cyber security, leaving the business fundamentally exposed to unmitigated risks
1. Ad-hoc / Informal: Security activities and roles are fulfilled on an “ad-hoc or informal basis”. Risks are resolved informally or ignored locally, and the organisation’s approach to security relies entirely on reactive measures rather than a documented strategy.
2. Documented / Partially Achieved: The organisation has planned its approach and retains “documented information” covering its security policies and procedures. However, these practices are only “Partially Achieved” because implementation may be inconsistent, or policies are occasionally circumvented to achieve business objectives.
3. Implemented / Achieved: Security processes and controls are formally “established, implemented, [and] maintained” across the organisation. The organisation meets the typical characteristics of an “Achieved” outcome, meaning policies and procedures are universally followed, appropriately resourced, and championed by management.
4. Monitored and Evaluated: The organisation actively conducts “monitoring, measurement, analysis and evaluation” of its security controls. Security performance is regularly tested, validated against threat intelligence, and reviewed by management to ensure it operates exactly as intended.
5. Continually Improved: The organisation focuses strictly on “continual improvement”. It proactively uses “lessons learned” from security incidents, threat hunting, and independent audits to continuously update, strengthen, and optimise its security posture ahead of emerging threats.

When would you want to use Control Maturity?#

Several triggers may indicate that your organisation is ready to adopt Control Maturity. Consider starting when:

• You have implemented, or are close to finalising, your initial set of controls.
• You are ready for an objective, independent assessment of your security posture.
• You need to align your program with frameworks that utilise maturity models (e.g., NIST CSF).
• You, your Board and/or key stakeholders require a measurable score to demonstrate program improvements and progress over time.

When should you not use Control Maturity?#

There is no reason to explicitly not use control maturity if you find it helpful, but before you set ambitious targets for maturity and drive towards them it’s often better to implement most or all the controls you have selected to treat your risks and then focus on optimising them. This could be as simple of setting an initial target of 1 or 2 for all your controls or just not worrying about maturity until you are in the position to look at what controls need to be progressed beyond that stage

How would I start using Control Maturity in the platform?#

You can launch Control Maturity assessments directly from the Risk Management Plan (RMP) view.To start, navigate to your RMP view, where you can define current and target maturity levels for each of your controls using a two 0-5 point scales:

• Current maturity - to capture where you are now.
• Target maturity - to define where you want to be.

By selecting a primary framework, you can use the maturity level or labels provided by that framework. If the framework doesn’t supply framework labels, we will default to the Cydea standard labels.

1. Core Scoring Logic

• Against a Control Framework: Control maturity is always measured against a framework within the Cydea risk platform.
• Direct Control Averaging: We calculate maturity overall based on the direct mathematical average of all underlying framework controls. This also applies to any group of controls e.g. Identify in NIST or Technology controls in ISO.
  Note: We always average the underlying controls to prevent statistical distortion rather than averaging intermediate sub-tier averages.
• Multi- Control Aggregation: When multiple custom controls map to a single source framework control, their scores are averaged first to establish the framework control’s effective score. e.g., custom controls scored at 2 and 4 both mapped to ISO 27002 5.2, the platform averages those custom control scores first ((2 + 4) / 2 = 3) so in this case the effective score is 3.
• Scope of Included Data: The score calculation factors in controls across active and planned states (Live, In Progress, or Not Started). This ensures documented controls with future target implementation dates are included to accurately project the organisation’s evolving posture.
• Excluded Controls: To prevent skewing the overall maturity baseline, any control marked as Not Applicable, Retired, or Abandoned as well as controls with null/empty maturity values are explicitly excluded from calculations.

These calculated averages are displayed on the interactive spider (radar) charts and summary tables, allowing security teams and executives to run gap analyses comparing current baseline scores against target goals.

Contact support if you’d like to make feature requests related to Control Maturity, for example using your own maturity labels within the workspace. As with any idea it will be considered as part of our roadmap prioritisation.