Consider adding control maturity scores to audits, much like there is compliance efficacy?
It makes more sense to me for the control maturity to be carried through to the compliance rather than setting an arbitrary percentage in the compliance module.
In theory the process could work as follow, when conducting an audit, the auditor scan score the maturity of the results, say using the well known control maturity model…
20% Initial (chaotic, ad hoc, individual heroics) - the starting point for use of a new or undocumented repeat process.
40% Repeatable - the process is at least documented sufficiently such that repeating the same steps may be attempted.
60% Defined - the process is defined/confirmed as a standard business process
80%Capable - the process is quantitatively managed in accordance with agreed-upon metrics.
100% Efficient - process management includes deliberate process optimization/improvement.
This can then be fed to the control, and in turn risks.
It could be possible to then use the user calculated risk analysis score and automatically set the treated risk score by using the control maturity, and the treated score would be reduce overtime as the control matures?
The maturity of the controls would also impact the compliance as controls get mapped to the compliance items?
Thoughts?
@phillip_rice I track maturity using custom fields but I do like the idea of maturity helping to establish residual risk in a more non-subjective way. You would need to be able to set a target maturity score because not all controls need to be at a level 5. Risk levels and business needs help to drive the target maturity level of a given control.
Eramba inherently establishes maturity through the mappings to the other security sections. A control that doesn’t have a mapped supporting policy and or procedure would indicate a control capability of Initial (level 1). If the control has mapped policies and procedures and those documents have been published (not in draft), I would look at this control as a capability level 3. A level 2 control might have a policy and/or procedure but it’s in draft or you have a policy but no supporting documents (e.g., procedures, standards, guidelines). Once you have established the control audit methodology and success criteria, this would then support a level 4 maturity since you have created metrics and KPIs for testing the efficacy and efficiency of the control. You could then use Eramba’s project improvement functionality to track optimization/improvement (corrective action) projects to support a level 5 maturity.
@kisero thoughts?
@blair.charleville
I think of it as risk based, so rather than setting targets on controls, you have a risk threshold that you work to meet until the risk is reduced to an acceptable level, this means you would continue to improve your controls overtime, increasing maturing to reduce the risk. The target is the risk appetite.
I understand about your thought relating to eramba mapping policy, proceedure etc, In my mind that is more about the maturity of the management system. I am really focussed on the control maturity (annex A in iso 27001), you could have a very basic procedure mapped to your control, like checking user access, via a manual ad-hoc process, you then mature that process, to be automated, following that you introduce metrics etc, as you can see, the procedure is present in all cases, its just the level of details/maturity which improves.