We have several sayings in our company that I like to repeat publicly. The first is “Security is a process not a product,” meaning security is something you do rather than something you buy or even something that you are. It is people and systems doing something normally all day, every day—that is security and not just in the sense that what they do keeps us secure. Of course, the process of doing security is what keeps us secure by definition, but it is the process that keeps us secure, not the products that are used in the process (nor even the people who are not always part of every process).
My second saying is “Security is more like accounting than it is like firefighting.” Both are processes, but accounting is something you do every day when you process transactions or analyze data, whereas firefighting is something you do on occasion and in response to something causing harm. Notably firefighting is reactive, whereas accounting is proactive. Yes, there is something very much like firefighting in cybersecurity in the form of incident response, and that too is a security function. But day in day out, and even statistically speaking, firefighting is practically absent. Security events occur every day, and many can be called “incidents.” However, the necessary response does not resemble firefighting. A day in the life of a security analyst or even a security engineer involves categorizing events identified by security systems, finding ways to tune those systems, configuring systems to address gaps in visibility, and measuring and reporting status and progress. That is a lot more like bookkeeping, audits, and reports.
My favorite saying is “because security gives us freedom” in the sense of the freedom to focus on other things with confidence. But this is more than offloading a burden. It is about operational excellence. Any cybersecurity or even information technology (IT) professional will tell you how valuable it is to simply design and run systems well. Keep backups. Take inventory. Document your processes. Validate important actions like onboarding and offboarding employees. Log everything. Develop metrics. Plan and test and test again. The financial world understands this, and the initial operational standards used in IT stem from those. This operational excellence enables us to scale, do more, and identify pain points, bottlenecks, and opportunities. It gives us freedom.
Like any field, cybersecurity has its standards and established methods, but despite how much is documented and readily available, the practice is highly fragmented and surprisingly nonprescriptive. Standards, common practices, frameworks, convergence via external pressures, and resources like MITER CVE, ATT&CK, VirusTotal, professional organizations and training, conferences, and community, are heavily leveraged, but it is left to the organization to use them. It is highly valuable to use a framework in your cybersecurity plans as it will give you some alignment with the industry and maybe even some cover when compliance applies. But compliance does not equal security. That takes maturity.
The National Institute of Standards and Technology (NIST), Department of Defense (DoD), Cybersecurity and Infrastructure Security Agency, and many other organizations and private entities have developed their own concepts of maturity levels. The Cybersecurity Maturity Model Certification from the DoD even describes its certification levels in terms of maturity, although they refer to granularity of controls rather than overall methods and practices. Even in writing this commentary I had to review several different published cybersecurity maturity models, each with a different language and different priorities. For a general understanding, the model that I find useful is derived from NIST’s Cybersecurity Framework (CSF). My intention is to enable the practitioner to understand more about their own practice and organization without trying to fit them into any particular framework. Further work would be dictated by industry and regulatory compliance requirements or existing organizational practice.
I. CYBERSECURITY MATURITY LEVELS
Let us take a look at the NIST cybersecurity maturity levels. There are different descriptions used in the industry, but the general breakdown is agreed upon.
Cybersecurity maturity levels refer to the stages of development that an organization goes through in establishing and maintaining effective cybersecurity practices. These levels typically range from basic or ad hoc security measures to highly advanced and proactive security strategies.
The following are typical cybersecurity maturity levels:
Initial: At this level, cybersecurity measures are typically reactive and ad hoc. There is little-to-no formalized process for managing security risks, and security measures are implemented in a piecemeal fashion as issues arise.
Characteristics: unpredictable, incomplete, high risk.
Repeatable: Organizations at this level have started to establish formalized cybersecurity processes and procedures. There is a strategy for managing security risks, and basic security controls are in place. However, these processes may still be somewhat inconsistent or not fully integrated into overall business operations.
Characteristics: reactive, volatile, manual.
Defined: At this level, organizations have implemented mechanisms for measuring and quantifying cybersecurity effectiveness. Key performance indicators and metrics are used to assess the performance of security controls and processes. Security incidents are tracked and analyzed to identify trends and areas for improvement.
Characteristics: documented, standardized, reviewable.
Managed: Organizations at this level have achieved a high level of maturity in cybersecurity. Security processes are continuously monitored, evaluated, and optimized for efficiency and effectiveness. There is a proactive approach to identifying and mitigating security risks, and security controls are integrated across all aspects of the organization’s operations.
Characteristics: proactive, track metrics, some automation.
Optimized: This is the highest level of cybersecurity maturity, where organizations have advanced capabilities for predicting and adapting to emerging threats. Security measures are highly adaptive and responsive to changing cyber risks and evolving business needs. The organization has a mature cybersecurity culture where security is ingrained into the fabric of the organization, and all employees are actively engaged in managing cyber risks.
Characteristics: automated, integrated, predictable.
II. THE ORGANIZATIONAL IMPACT OF DIFFERENT LEVELS OF MATURITY
Assessing cybersecurity maturity levels can help organizations identify areas for improvement and prioritize investments in cybersecurity initiatives to enhance their overall security posture. Obviously, it is desirable to achieve the highest level of maturity, and, of course, in doing so, it takes more time and money to achieve higher maturity. But the value derived from operational improvement can offset that cost. Much of the cost comes from initial work and architecture changes. Security product costs can be high and, with many products shifting to subscription pricing, the costs do not go away. But a good design and careful consideration of products used can make a big difference by avoiding subscriptions where possible and by reducing product overlap. Building maturity takes time. The shortcut to maturity is outsourcing, but costs can be higher, especially if an internal team is experienced and can optimize. Outsourcing can cost less particularly when providers bring their own tooling (products) to gain economies of scale.
None of the above points take into account the value of not experiencing a security incident. The cost of an incident can be so high as to be existential, even for a large organization. Insurance has limits and does not cover many situations. To weigh spend versus the cost of an incident, an organization must take their risk appetite and risk tolerance into account, similar to how other risk exposures (financial, privacy, reputational, and physical) are evaluated. In other words, involve your Chief Financial Officer and Risk Officer, not just the Chief Information Officer and Chief Information Security Officer.
Risk appetite is the amount of risk, perhaps in dollars, that an organization is willing to accept. This is similar to the way insurance is purchased, with a financial calculus. Individuals do not buy insurance they do not need, that is when they can afford the claim themselves. They pay less for insurance and accept a bigger deductible. The same goes for cybersecurity maturity. The highest maturity is desirable, but the cost of achieving it may not be necessary. A less mature system might still represent minimal exposure and associated costs of an incident. In that case, the organization may accept more risk to save budget.
Then there is risk tolerance, which is not the same. Risk tolerance represents more about the value of the organization itself or rather the value of overall impact of an incident. It is the amount of risk beyond which the organization cannot accept. If an organization cannot survive certain types of impact or is otherwise forced or constrained by regulations or third-party pressures to not tolerate certain impacts, it is their risk tolerance that goes up. The organization cannot, therefore, tolerate these risks or at least some level of financial impact. It is easy to make the mistake of calculating risk appetite while ignoring risk tolerance. Ultimately risk appetite should be lower than risk tolerance, in which case there should be an acceptable level of spend and risk. If tolerance is lower, there is a problem. Either the appetite must come down, which means more spending, or the organization has to mitigate the risks with a structural change, sometimes with divestment or mergers and acquisitions.
III. IMPACT OF EACH LEVEL ON BUDGETS
Achieving these levels can come at a high cost, but a low maturity level poses great risk, and the incremental cost of reaching level 3 or 4 can be low because most of the changes have to do with policies and practice rather than products or a great deal more staffing.
A level 1 organization may save money by not having staff to react to problems, but problems will soon be massively disruptive if not existential. Level 2, where there is a resource to react with manual changes, makes a big difference with the added cost. An event such as a new vulnerability on a critical system will at least be addressed at some point and minimize harm. But those additional resources, typically in the form of staff or a third party, can move the organization to level 3 with the simple and careful work of documenting systems and processes, including policies and procedures for things like response and offboarding staff. To truly reach level 3, an organization must at least review systems and document processes. This mainly takes additional effort once the cost of level 2 has been made.
Level 4 is harder to attain without adding cost. It requires data collection and typically higher-end systems that can be integrated with centralized data collection. A practice must be in place that leverages visibility into systems for a continuous review and identification of vulnerabilities. A cadence of improvement must also be in place. Typically, this requires additional systems costs and more staffing or outsourcing.
Level 5 requires a significant investment. Protection systems need to work in concert with automation in place where possible. Visibility must be very high, with data ingestion fully automated, continuous, and analyzed on an ongoing basis. Detection becomes the focus above established protection. Although systems costs rise primarily due to the necessity for enterprise-level systems to integrate with security monitoring and controls, the main additional cost is the additional staff required.
To be clear, although maturity levels are indeed sequential, they are not always achieved this way. An organization can reach a maturity level in one way but remain lacking in another, and one improvement may inform another. To make this easier to manage, we can break our focus down into domains.
IV. ASSESSMENT DOMAINS
Each organization will want to assess its own level of cybersecurity maturity, but to do so, it is useful to break down its cybersecurity program into domains and assess each individually. The following domains are derived from the NIST CSF, with v.2 recently released (NIST 2024).
Governance
Security oversight and governance
Identification of what needs to be protected
Adherence to policy and processes
Priorities based on ROI
Scope of attack surface
Metrics reporting that reveals the threat landscape
Identification
Asset and process inventory
Vulnerability and configuration management
Threat intelligence controls
Protection
Current degree of implementation
Current degree of effectiveness protecting business operations, reputation, and overall value
Detection
Assessment of vulnerabilities, changes, and new risks to assets
Network traffic baselines
Logging activity and information
Response
Current ability to contain incidents, resolve them, and restore functionality
Response plan for relevant threats
V. ASSESSING EACH DOMAIN
There is no one-size-fits-all for security assessments, nor is it simply affected by the size of the organization. The primary parameter that factors in is the organization’s risk appetite. This is because, like the practices needed to achieve higher levels of security maturity, they cost more. Even very large and complex organizations can choose to simply assess certain core systems or their set of policies and procedures or certain domains. Others perform an automated scan and call it an assessment. None of this is inherently wrong, and it is often driven by minimally adhering to some compliance requirement, but there is risk involved in doing less. There will always be security gaps in any system or process, and each one exposes an organization to risk. An organization with a high risk appetite may choose to leave gaps open and not increase its budget, but you have to know the risks to determine if it is within your appetite. The organizations that have been severely affected by a security incident very likely were not adequately aware of their risks, and their risk appetite ended up being above their risk tolerance.
But there also is a lost opportunity when an organization chooses to minimize the scope of their security assessment beyond not identifying their risk. They lose the opportunity to identify areas of improvement that affect them operationally. Often these findings lead to cost savings and strategic changes. Just the process of interacting with an assessor is powerful and informative, whereas so many are just focused on the day to day and not improving. It is better to have been through an assessment before having one done for compliance if only to find out about poor performance.
Each of the domains of security assessment are relevant and integrated. Some organizations may choose to only cover certain ones to save time and money, and the domains do differ in cost and value. Just as organizations evaluate the level of maturity in each domain, the assessment is also affected by that level. The most mature organization is practically running an assessment on an ongoing basis. Let us look at each domain and how that works.
The Governance domain is the easiest and least expensive to do only because it is simply reviewing documented practice. Any level of maturity above level 1 will have some procedures and controls documented. The assessor simply reviews these and can determine the level of maturity. If the organization lacks documentation, there is no point in performing an assessment of the Governance domain. We know the score already. Interestingly this is also the least expensive domain to improve upon because there are not significant product or staff costs. It is simply tedious to do, and many information security leaders cannot find the time to get to it. It is also very difficult to outsource because producing documentation requires decision-making that an outside party cannot make for an organization.
The Identification domain is all about the inventory. If there is no inventory, then an assessment could produce it, making the process much more expensive. Discovering systems that are not documented requires scans that ideally should be run on a continuous basis. However, even one-off scans yield valuable results.
The Protection domain references systems and processes in place and how effective they may be. A full assessment can get complicated when an organization has not determined its risk appetite because protections have inherent limitations. Often the assessment is expected to recommend a risk appetite in the Protection domain specifically, without the context of the organization’s financial strength and other factors. In addition, many organizations build systems outside the context of risk appetite or understanding their gaps and have introduced overlaps, redundancy, and unnecessary costs—something assessment is expected to unravel. The security assessment evaluates gaps in systems and practice and maps those to the protection systems in place. It works within the existing architecture, not a hypothetical one.
The Response domain is similar to the Governance domain in that it can only be evaluated if there is documentation, but systems and the ability to respond are also taken into account. Most relevant for high levels of maturity is simply having data. This is usually in the form of a Security Information and Event Management System that collects data from all systems and processes. With these data, a response procedure can make better decisions, and a forensics team can attest to the impact better. This highest level of maturity matters greatly when compliance rules require an organization to attest to any data exfiltration. Without knowledge of it, the organization must assume that data have been compromised, often amplifying the impact of the attack unnecessarily.
I left the Detection domain last for a reason. Detection is the highest form of security maturity. Assessing it requires not only evaluating systems and processes in place but also testing it such as with penetration tests. The power of Detection lies in its ability to provide situational awareness, not just to trigger protection. It empowers Response and enforces Governance. It even provides data to confirm Identification.
The greatest power of a highly mature Detection practice is that it reduces the risk of gaps that are too expensive to mitigate. Having greater or more targeted Detection can reduce risk when there is a conflict between risk appetite and risk tolerance.
Scoring
Simply answering questions about practices in place can give one a good sense of cybersecurity maturity, with only a few hours spent. The typical scoring system ranges from 0 to 5 overall and for each domain. This can be a useful guide and provides some focus, if only to start on the path of procuring a budget for cybersecurity assessment. Simply answering questions can be deceiving, especially if self-assessed. It is all too easy to ignore areas of deficiency or even be unaware of them.
Cybersecurity assessment backs a review with data to truly describe an organization’s current state and practices. Maturity levels then truly become a valuable metric that allows for focus on specific domains and improvements, while allowing the organization to track progress over time. The details in a cybersecurity assessment are also actionable in helping an organization gain knowledge about specific risks, allowing them to make data-driven decisions about their risk appetite and make the necessary adjustments.
For all these domains, scanning and assessment tools have become more data driven (albeit more expensive), and the industry provides far more guidance than it used to for keeping up with the severity of attacks by criminals. Cybersecurity maturity is attainable, especially if increased gradually over time. Each organization needs to start somewhere, and an initial assessment can provide momentum. This is not worthwhile without at least some preparation, and this is where the challenge lies.
Organizations are often driven simply by compliance, and service providers are not able to create incentives for organizations to do otherwise. With greater clarity and more prescriptive requirements, this gap could be reduced, making organizations more secure. Product companies can also help by aligning their offering with specific requirements, as with the most successful efforts from organizations like MITER, which maps and centralizes intelligence regarding cybersecurity (IBM 2024).
I hope this dose of reality will at least set expectations as your organization progresses. Do not just start spending money. Assess, plan, and prioritize, and move the needle every day.
