CTEM Self Assessment - Cutting Edge Security Services

CTEM Self Assessment Maturity Questionnaire

Read the questions below carefully. Click Next to move to the next set of questions or Previous to go back and review your answers.

Step 1 of 36

Welcome to the CTEM Maturity Self‑Assessment Questionnaire

CTEM - Continuous Threat and Exposure Management

CTEM is a proactive, data-driven framework for managing cyber risk, shifting from reactive security to continuous, integrated exposure management. It helps organisations understand how accessible, exposed and exploitable their digital assets are to cyber threats, leading to better risk management. For each question, select the option that best describes your organisation's current state. Each option has a weighted score, which will be used to calculate your overall CTEM/TID maturity.

About this self-assessment questionnaire
This questionnaire includes 67 questions across four domains. It is designed to give you a clear view of where you are on your CTEM journey and the maturity of key subdomain capabilities.

The four domains are:

Technology
Business
Governance
Vision and Mission

How to complete it:

Choose the option that best reflects how your organisation operates today, not how you plan to operate.
Each response has a weighted score. At the end, you’ll see your domain maturity and overall score.
Allow 30–45 minutes. A coffee won’t hurt.

Ready to start? Click the button below to begin.

Domain 1: Technology

This domain covers your organisation's technical capabilities and security tools used for identifying, evaluating and mitigating cyber threats and exposures. This domain encompasses security controls, vulnerability management, threat intelligence and incident response as key components.

Vulnerability Management

1. How does your organisation prioritise vulnerabilities identified in systems and applications?(Required)

Solely based on technical severity (e.g., CVSS scores), with reactive patching.

Based on technical severity, but with some consideration for business impact.

Prioritisation considers business impact, compensating controls and threat intelligence.

Automated prioritisation leverages threat intelligence, exploitability and real-time attacker activity.

Proactive vulnerability discovery and continuous assessment of exposure are embedded in relevant processes.

2. What best describes your vulnerability remediation process?(Required)

Reactive patching based on CVE scores with limited scanning.

Regular vulnerability scanning, but remediation is often manual and inconsistent.

Vulnerability remediation workflows are partially automated and integrated with patch management systems.

Proactive vulnerability discovery and mitigation, with continuous assessment of exposure.

Remediation efforts are based on actual exploit activity and business criticality, with automated deployment and testing.

3. To what extent has your vulnerability management (VM) program evolved from a traditional, reactive approach to align with modern CTEM principles?(Required)

Our VM is primarily reactive, focusing on patching vulnerabilities based on technical severity (CVSS) scores from scheduled scans, with limited consideration for continuous improvement or emerging threats.

We are beginning to incorporate some threat intelligence into VM and consider business impact for prioritisation, but it's not yet a continuous or holistic approach.

Our VM program actively integrates threat intelligence and business impact for prioritisation and we have established processes for continuous monitoring, though full automation is limited.

Our VM is part of a broader CTEM initiative, systematically leveraging real-time threat intelligence, exploitability data and dynamic business context to prioritise and proactively reduce attack paths, with increasing automation.

Our VM program is fully integrated within a mature CTEM framework, with advanced automation driving proactive vulnerability discovery, continuous assessment of exposure and adaptive security controls based on predictive analytics of emerging threats.

Configuration Management

4. How are security configurations managed across your IT environment to continuously reduce exposure?(Required)

Configuration management is ad-hoc, with limited formal processes or consistent standards for security settings.

Basic security controls are implemented, often with default settings and cross-control integration for security configurations is limited.

Multi-layered security controls provide decent coverage, with some initial cross-control integration and limited automation for configuration management.

Cross-control integration is established with automated playbooks to manage configurations and these controls are actively monitored for continuous compliance.

Controls are actively monitored for compliance and continuous testing and validation systematically drive improvements in security configurations, tracking gaps and deficiencies, leveraging automation for proactive adjustments.

5. To what extent are technology teams actively involved in ensuring and maintaining secure configurations across your IT environment?(Required)

Security configurations are primarily managed by a small, centralised security team, with limited direct involvement from technology operations.

Technology teams implement security controls as directed but have minimal proactive involvement in CTEM initiatives or ongoing secure configuration efforts.

Technology teams contribute by providing data and insights about technology assets and configurations for security risk assessments related to secure configurations.

Technology teams actively collaborate with security teams to implement and maintain secure configurations, contributing technical insights and ensuring configurations align with CTEM initiatives.

Security considerations are fully embedded into the daily operations and workflows of technology teams, fostering a shared responsibility for continuously ensuring and improving secure configurations.

Threat Intelligence

6. How is threat intelligence utilised within your organisation?(Required)

Limited or ad-hoc threat intelligence gathering, often not integrated into security operations.

Formal threat intelligence processes established, with some integration into risk assessments

Threat intelligence informs red teaming exercises and validates security controls.

Proactive threat hunting is based on intelligence, with tailored briefings for stakeholders.

Threat intelligence drives automated security orchestration and incident response, with real-time feeds.

7. What level of understanding do your security teams have regarding relevant threat actors and attack vectors?(Required)

Basic awareness, relying on generic threat feeds.

Formal threat intelligence processes are established, but integration with security operations is limited.

Threat intelligence is integrated into risk assessments and vulnerability prioritisation.

Threat actor profiles are detailed, including motivations, financial resources, and targeting patterns.

Threat intelligence proactively guides hunting activities and informs board reporting.

8. How effectively is threat intelligence integrated into the design and risk assessment of new applications or services?(Required)

Threat intelligence is rarely or informally considered during new application/service design or risk assessment.

Basic threat intelligence is reviewed during the design phase, but its impact on risk assessment is limited.

Threat intelligence informs the initial risk profiling of new applications and some security requirements are derived from it.

Threat intelligence is systematically integrated into threat modelling for new applications/services, driving secure-by-design principles and comprehensive risk assessments.

Automated pipelines continuously feed real-time threat intelligence into the design and deployment of new applications, enabling adaptive security controls and dynamic risk profiles.

9. To what extent does your organisation utilise threat modelling as a means to anticipate attack paths and inform security controls for critical systems?(Required)

Threat modelling is ad-hoc or rarely performed, with little impact on security control implementation.

Basic threat modelling is done for some systems, primarily to identify known vulnerabilities.

Threat modelling is performed for critical systems, helping to understand attack vectors and potential attack paths.

Threat modelling is regularly updated and integrated with threat intelligence to identify relevant attack scenarios and inform the prioritisation of security controls and mitigations.

Automated threat model generation and continuous refinement are used to dynamically adapt security architecture and controls to emerging attack paths.

Incident Management

10. How are security incidents detected, responded to and recovered from?(Required)

Reactive response to incidents, with limited formal plans.

Basic incident response planning and execution, but often manual.

Incident response is based on severity, with some evidence gathering.

Threat intelligence and exposure management data are integrated into incident response plans.

Regular testing and validation of incident response efforts are conducted to identify areas for improvement.

11. Which of the following best describes the scope of involvement of different organisational stakeholders in your incident response processes?(Required)

Incident response is primarily handled by the security team and IT, with limited formal involvement from other departments.

Key stakeholders like incident response teams, IT, and legal/communications teams are involved, but cross-functional coordination is often ad-hoc.

Incident response involves dedicated teams, IT, legal, communications, and actively engages some business owners for critical incidents.

Clear incident response roles and responsibilities are formally defined and consistently engaged across departments, including HR and legal, for all relevant incidents.

Business continuity and crisis management plans are fully integrated with cyber incident response, involving executive leadership and all critical business functions in a coordinated and regularly tested manner.

12. How comprehensive and regularly tested are your incident response playbooks?(Required)

Incident response relies on informal procedures or basic checklists, with no formal playbooks.

Basic playbooks exist for common incidents but are not regularly updated or tested.

Formal incident response playbooks are defined for various scenarios and are periodically reviewed and updated.

Incident response playbooks are comprehensive, threat-informed and regularly tested through tabletop exercises and live simulations (dry runs) involving relevant stakeholders.

Automated playbooks are dynamically updated with real-time threat intelligence and are continuously validated through breach and attack simulations to ensure optimal response.

13. To what extent does your organisation leverage cyber insurance or engage external parties for specialised incident response capabilities (e.g., threat hunting, forensics)?(Required)

We do not have cyber insurance and rarely engage external incident response support.

We have basic cyber insurance and external support is engaged reactively for major incidents.

Cyber insurance coverage is in place and contracts with external incident response firms (e.g., Mandiant) are established for specialised support when needed.

Cyber insurance policies are regularly reviewed based on CTEM insights and external threat hunting or forensic expertise is proactively engaged to enhance internal capabilities and validate defences.

Cyber insurance policies are regularly reviewed based on CTEM insights and external threat hunting or forensic expertise. External incident response partners are integrated into continuous CTEM validation and mobilisation phases, providing proactive threat hunting and continuous improvement feedback.

Security Testing and Validation

14. What is the scope and frequency of your security testing activities(Required)

Limited or infrequent security testing.

Regular penetration testing, but limited scope and focus on technical vulnerabilities.

Threat-informed penetration testing and red teaming exercises, including attack path analysis.

Breach and attack simulations are employed in conjunction with threat-informed insights to support continuous security validation through automated tools.

Security testing and validation is a mature and automated practice, leveraging several tools and threat-informed insights to integrate with the development lifecycle, with proactive security posture assessment.

15. How do you validate the effectiveness of your security controls and defences?(Required)

Rely on internal audits and compliance checks.

Ad-hoc testing or reviews are conducted when issues arise.

Security testing validates the effectiveness of security controls and remediation efforts.

Automated security validation tools continuously assess control effectiveness against real-world attacks. Controls effectiveness is monitored and tracked regularly.

Adversary emulation and attack simulations are conducted to test defences and response against specific threat actors. Controls effectiveness is tracked against predefined metrics such as 'Design Effective' and 'Operating Effective'.

16. How comprehensively do your security testing activities (e.g., penetration testing, red teaming) cover diverse attack techniques, including those specific to your industry or emerging threats?(Required)

Testing is limited to basic vulnerability scanning and generic penetration tests.

Penetration testing covers common attack techniques, but is not specifically informed by relevant threat intelligence.

Threat-informed penetration testing and red teaming exercises consider specific attack techniques and paths relevant to the organisation

Testing actively emulates sophisticated adversary tactics, techniques, and procedures (TTPs) and adapts to emerging threats and industry-specific attack trends.

Continuous security validation leverages advanced adversary emulation scenarios and incorporates real-time threat intelligence to test defences against novel attack methods across the entire attack surface, with continuous learnings to cover industry and/or geography specific attack campaigns and respective TTPs.

17. How are the findings from security testing (e.g., penetration tests, red team exercises) integrated back into your CTEM processes to drive remediation and improve overall security posture?(Required)

Testing results are delivered as reports, with manual effort required to initiate remediation.

Findings are tracked, but their integration with vulnerability prioritisation or incident response is inconsistent.

Security testing results are used to validate the effectiveness of existing controls and inform remediation priorities.

Findings from security testing actively feed into the CTEM prioritisation phase, adjusting risk scores, informing specific remediation actions and are used to refine threat models and security controls.

Automated workflows ensure security validation findings trigger immediate remediation actions and provide continuous feedback to improve security architecture, threat intelligence and incident response playbooks.

External Attack Surface Management

18. How does your organisation monitor and assess its external attack surface?How are the findings from security testing (e.g., penetration tests, red team exercises) integrated back into your CTEM processes to drive remediation and improve overall security posture?(Required)

Limited visibility into external attack surface, no formal asset inventory.

Some visibility into the external attack surface with basic asset discovery and inventory, with limited exposure assessment.

Comprehensive asset inventory, automated exposure assessments and ongoing attack surface monitoring.

Ongoing attack surface management with an integrated exposure management platform, including real-time risk visibility and prioritisation.

Proactive external attack surface management and exposure reduction through security orchestration, threat-informed insights and continuous monitoring of emerging threats.

19. What are the key steps taken to protect your brand reputation from external threats?(Required)

Ad-hoc monitoring for major brand abuses, usually after they occur.

Identifying and mitigating risks like impersonation and phishing, but often treated as reactive means.

Some brand posture management capabilities with continuous monitoring and assessment of the organisation's digital footprint as it appears to external actors.

Continuous brand posture management with prioritising remediation efforts based on the severity of vulnerabilities and potential impact on brand reputation.

Continuous brand posture management with security control effectiveness monitoring to prioritise remediation work and to validate the closure of remediation actions for ongoing brand protection.

20. How effectively does your organisation continuously discover and inventory its internet-facing assets, including unknown or "shadow IT" assets?(Required)

Discovery of external assets is largely manual or ad-hoc, with significant blind spots.

Basic asset discovery tools are used, but a comprehensive and continuously updated inventory of external assets is lacking.

Automated external attack surface management (EASM) tools are used to monitor internet-facing assets, identify new exposures and maintain an accurate inventory..

An integrated EASM platform provides real-time visibility into the organisation's entire digital footprint, including shadow IT and third-party exposures, informing CTEM scoping and enabling an accurate inventory.

External attack surface monitoring is fully automated and integrated with threat intelligence and vulnerability management platforms for dynamic identification, proactive reduction of emerging exposures and real-time visibility across asset inventory.

21. How proactively does your organisation identify and mitigate brand impersonation, phishing domains, and other external threats targeting your brand reputation?(Required)

Brand protection is reactive, primarily responding to reported incidents of impersonation or phishing.

Basic monitoring for brand abuses is performed, but remediation is often delayed.

The organisation actively monitors for brand impersonation and phishing domains, with some automated takedown efforts.

Proactive brand protection strategies leverage threat intelligence and external posture management tools to rapidly identify and mitigate risks such as impersonation, phishing, and negative social media campaigns.

Brand protection is fully integrated into the CTEM cycle, with automated workflows for detecting, validating and neutralising external threats to brand reputation, informed by real-time intelligence on attacker tactics.

Third-Party Risk Management

22. How does your organisation manage risks associated with third-party vendors and the supply chain?(Required)

Ad-hoc and limited third-party risk assessments, mainly during initial contracting.

Basic due diligence on third-party vendors conducted, but inconsistent monitoring.

Risk assessments and due diligence are conducted on third-party vendors, with some vendor risk monitoring.

Risk assessments and due diligence are conducted on third-party vendors, with vendors and risks prioritised based on their potential impact on the organisation.

Automated third-party risk management, with validation of vendor security controls effectiveness and the incorporation of vendor security requirements into contracts.

23. What is the involvement of third parties in your CTEM initiatives?(Required)

Third parties are only involved if a security incident occurs.

Limited collaboration, primarily focused on compliance audits

Mutual audit rights are defined in contracts.

Joint CTEM workshops are held with vendors to align on shared responsibility matrices.

Contractual CTEM clauses and cross-business processes are in place to achieve third-party compliance and ongoing effective risk management.

24. How are security requirements and compliance with CTEM principles enforced through contractual clauses with third-party vendors?(Required)

Security requirements for third parties are generally vague or not explicitly enforced contractually.

Standard security clauses are included in contracts, but specific CTEM-related requirements are limited.

Contracts include clear security requirements and some include mutual audit rights or basic security performance clauses.

Contractual CTEM clauses are utilised to achieve measurable third-party compliance and ensure alignment with shared responsibility matrices and risk mitigation efforts.

Vendor contracts are dynamically updated to reflect evolving threat landscape and CTEM best practices, with performance-based incentives for proactive security and continuous validation.

25. How actively does your organisation manage and monitor the cyber risk posture of critical third-party vendors beyond initial assessments?(Required)

Third-party risk management is largely limited to initial assessments during vendor onboarding.

Periodic reviews are conducted for some critical third parties, but monitoring is inconsistent.

Continuous monitoring of critical third-party security posture is performed, often through security ratings platforms or regular attestations.

The cyber risk of critical third parties is actively managed through joint CTEM workshops, shared responsibility frameworks, and threat intelligence sharing to address emerging supply chain risks.

Automated tools continuously assess and validate third-party security controls against real-world threats, with findings integrated into the organisation's overall CTEM prioritisation and remediation efforts. Joint CTEM workshops are conducted to derive learnings and enable continuous improvement.

Domain 2: Business

This domain emphasises integrating cybersecurity into core business processes and decision-making, empowering business owners to manage cyber risk and aligning security initiatives with business goals.

Asset Criticality Metrics

26. How does your organisation maintain an inventory of critical business functions, supporting technology and data assets?(Required)

Limited or informal inventory, often maintained in disparate spreadsheets.

Basic inventory, but often outdated or incomplete.

A complete inventory of key business functions, supporting technology and data assets is maintained.

A comprehensive business asset inventory is regularly reviewed and updated.

Automated asset discovery tools are used to maintain an enterprise CMDB, covering technology, business functions and data assets.

27. How effectively is your Business Asset Inventory or CMDB integrated with other security functions to support CTEM objectives?(Required)

Our asset inventory is largely ad-hoc or incomplete, with no formal integration with other security functions.

A basic asset inventory exists, but its integration with other security tools is limited and often outdated.

Our comprehensive asset inventory is making efforts to integrate with security functions like vulnerability scanning or basic security monitoring.

Our CMDB is regularly updated using automated discovery tools and is integrated with vulnerability management and threat intelligence platforms to actively inform prioritisation.

Our asset inventory is continuously updated in real-time via automated discovery and is fully integrated with CTEM processes (e.g., threat intelligence, vulnerability, and incident response) for dynamic risk assessment and proactive decision-making.

28. To what extent does your asset inventory clearly map to defined business and technical owners and how is this ownership leveraged in security processes?(Required)

Asset ownership is largely informal or undocumented, with limited impact on security processes.

Some assets have identified owners, but this information is not consistently used for security decision-making or accountability.

Critical assets are mapped to business and technical owners and this information is occasionally used to inform security assessments or remediation.

Asset ownership is clearly defined for most critical assets, enabling active involvement of owners in risk acceptance, control implementation, and vulnerability remediation processes.

A formal shared accountability framework ensures clear accountability for the security of specific applications and services, integrating business ownership deeply into CTEM processes and remediation efforts, with measurable objectives assigned to departments.

Business Asset Inventory

29. How does your organisation assess and define the criticality of business assets?(Required)

Criticality is vaguely understood, not formally defined.

Basic assessment of criticality, but not consistently applied.

Formal processes in place for assessing and defining the criticality of business assets based on their importance to operations.

Formal processes in place with criticality assessments integrated into CTEM scoping and prioritisation.

Processes are reviewed and tested ongoing with measurable metrics that are developed to quantify risk and the impact of potential disruptions on critical assets.

30. What is the level of business unit involvement in defining and applying asset criticality for cyber security prioritisation?(Required)

Business units have minimal input; asset criticality is primarily determined by IT or security teams without significant business context.

Business owners are occasionally consulted for input on asset criticality, but their involvement is not standardised or consistently applied.

Business owners are consistently engaged in Business Impact Analysis (BIA) exercises to formally define system and data criticality, which informs security prioritisation.

Asset criticality is a cross-functional effort where business units, including finance and legal/compliance, actively quantify potential impacts (e.g., revenue, regulatory obligations) to dynamically prioritise assets.

Business units are fully empowered and accountable for defining and continuously refining asset criticality, with their input directly overriding or informing technical prioritisation based on real-time business context and risk.

Risk Register

31. How is cyber risk documented and tracked within your organisation?(Required)

Ad-hoc, with no formal risk register specific to cyber.

A basic risk register exists, but it's updated periodically and lacks dynamic context.

A comprehensive GRC framework is implemented, including a risk register and key risk indicators.

Risks are prioritised based on potential business impact and risk appetite within the GRC framework.

Risks are prioritised based on potential business impact with a risk register that is continuously updated based on empirical data and business context.

32. How does your organisation systematically identify, assess and prioritise cyber risks? How are these priorities translated into security initiatives annually?(Required)

Cyber risk identification is reactive or informal, with no consistent process for annual prioritisation or initiative translation.

Basic risk assessments are performed periodically, but the connection between identified risks, their prioritisation and annual security initiatives is weak or ad-hoc.

Risks are identified and assessed within a GRC framework and high-priority risks are considered during annual security initiative planning.

Periodic risk assessments leverage threat intelligence and business impact analysis, to prioritise risks, which are formally reviewed and consistently translated into specific security initiatives with the appropriate resource allocation.

Continuous risk management processes are in place covering all key business applications while using real-time empirical data and dynamic business context to identify and prioritise risks, with automated workflows ensuring direct translation into an enterprise risk register and to prioritise funding for strategic CTEM initiatives.

33. To what extent do identified cyber risks have clear mapping to owners (business/technical) and how is the overall risk posture communicated to the Board?(Required)

Risk ownership is informal, and cyber risk reporting to the Board is limited or highly technical.

Some risk owners are identified and the Board receives periodic, but often high-level or compliance-focused, cyber risk updates.

Key cyber risks are mapped to responsible individuals or teams and ongoing Board updates include regular reports on cyber risk posture and security program effectiveness.

Risk ownership is formally assigned and tracked within an enterprise risk register with clear accountability frameworks and Board reports that provide clear, concise and actionable insights on cyber risk, focusing on business impact and strategic decision-making.

Risk ownership is deeply embedded with measurable objectives across departments with clear demarcation between business and technical owners. Executive dashboards are available to translate technical vulnerabilities into business risk narratives, including financial impact projections for Board-level strategic allocation.

Business Owners

34. In your organisation, what is the role of business owners in managing cyber risk?(Required)

Business owners are hardly involved and see cyber security as an IT responsibility.

Business owners are informed of risks but have limited direct involvement in mitigation.

Business owners are actively involved in risk acceptance discussions and collaborate on mitigation strategies and prioritisation of remediation activities.

Business owners are well informed and held accountable for risk acceptance and/or the timely remediation of vulnerabilities in their systems.

Business owners are empowered to understand and manage cyber risks within their respective areas, through the development of respective mitigation strategies.

35. How is accountability for cyber risk and security measures established for business units?(Required)

Accountability is informal or unclear.

Security team drives control implementation with some business input

Clear ownership and accountability for cyber risk are facilitated through communication of risk assessments.

Measurable security objectives (KPIs) are assigned across departments, e.g., for SaaS app permissions or employee access lifecycle.

Business owners are involved in security initiatives and control customisation and integration to balance security risk with operational efficiency.

36. How are business owners empowered and supported to manage cyber risks within their respective areas, including through training and awareness?(Required)

Business owners receive generic cyber security awareness training, but it is not tailored to their specific operational risks or responsibilities.

Business owners are informed about relevant cyber risks, but they have limited resources or tools to actively manage these risks within their departments.

Tailored cyber security awareness training programs are provided for different business units, addressing relevant threats specific to their operations and supporting their risk management role.

Business owners are actively involved in designing and implementing security awareness initiatives specific to their areas and are provided with data-driven insights to manage their cyber risks.

Business owners proactively drive a security-first culture within their units, leveraging threat intelligence and CTEM insights to continuously adapt their practices and demonstrate measurable risk reduction.

37. How are business owners actively involved in the selection, implementation and review of security controls relevant to their operations?(Required)

Business owners have minimal or no involvement in security control decisions, it is managed within IT and Security.

Business owners are informed about control implementations but have limited input or customisation options.

Business owners are consulted on control selection for critical systems and provide input on operational impact.

Business owners actively collaborate with security and IT teams on control implementation, ensuring alignment with business processes and operational efficiency while balancing security requirements.

Business owners are formally accountable for the effectiveness of security controls within their domains, with regular performance reviews tied to CTEM objectives and risk posture.

38. To what extent do business owners formally accept or reject cyber risks and how does this impact remediation efforts?(Required)

Cyber risk acceptance is informal or solely an IT/security team decision.

Business owners are made aware of risks, but typically do not formally accept them.

Business owners are involved in discussions about risk acceptance for noncritical issues and their input is considered.

Business owners formally accept residual cyber risks (after proposed mitigations) for their respective areas and this acceptance directly influences remediation prioritisation and resource allocation.

A transparent framework ensures business owners have visibility and take full ownership of cyber risk decisions, with formal sign-off processes that are regularly reviewed by the Board, allowing for clear accountability and strategic risk management.

Service Level Agreements (SLAs)

39. How are security-related performance targets and responsibilities formally defined and integrated into your Service Level Agreements (SLAs) for services and applications?(Required)

Security-related performance targets are not formally defined or included in our service-level agreements (SLAs).

Some basic security requirements are mentioned in general IT SLAs, but without specific performance targets or clear responsibilities.

Security requirements and responsibilities are explicitly defined within SLAs for critical applications and services, including basic performance targets.

Our SLAs formally incorporate Maximum Acceptable Outage (MAO), Service Level Objectives (SLOs) and clear security-related performance targets and responsibilities, which are regularly reviewed.

Our SLAs formally incorporate Maximum Acceptable Outage (MAO) and Service Level Objectives (SLOs). Security performance targets within SLAs are continuously refined based on real-time CTEM insights (e.g., critical vulnerability remediation impacting service availability), with automated tracking and reporting.

40. To what extent do security-related KPIs and performance targets exist for development teams and business units to drive shared accountability for security outcomes?(Required)

Security KPIs are primarily focused on the security team, with little or no direct targets for development teams or business units.

Some generic security KPIs exist for IT/development, but they are not consistently tied to business impact or shared accountability.

Security KPIs are defined for development teams (e.g., secure coding practices) and some business units, with basic reporting on adherence.

Measurable security objectives (KPIs) are assigned across departments (e.g., for SaaS app permissions, employee access lifecycle), fostering cross-functional collaboration and shared accountability for CTEM outcomes.

Advanced metrics (e.g., mean time to remediate for high-priority vulnerabilities affecting their services) are directly integrated into performance evaluations for development and business owners, with clear incentives for proactive security.

41. How are deviations from security-related SLAs or missed remediation targets addressed and is this reported to executive leadership or the Board?(Required)

Missed security targets are addressed informally or on an ad-hoc basis, with limited formal escalation

Some internal discussions occur when security SLAs are missed, but there are no formal penalties or high-level reporting.

Deviations from security-related SLAs trigger formal internal reviews and remediation plans are put in place.

Significant deviations from critical security SLAs or remediation targets result in formal accountability discussions with relevant business/technical owners and are included in executive-level security reports.

A transparent framework includes penalties or direct impacts on departmental objectives for consistently missing critical security-related SLAs, with regular, concise reporting to the Board on overall security posture and compliance.

Technology Operations

42. How do technology operations teams support the CTEM program?(Required)

Technology operations primarily focus on system uptime, with security as a secondary concern.

Technology operations provide data about technology assets and configurations upon request.

Technology operations contribute to risk assessments by providing technical insights.

Technology operations teams involved in CTEM initiative prioritisation discussions and actively involved in implementing security controls, managing configurations and supporting tool deployment.

Technology operations provide input on the feasibility and impact of CTEM initiatives, involved in CTEM prioritisation discussions and represented on relevant committees to ensure secure and reliable IT system operations.

43. How integrated are security considerations into your daily IT operations across various domains (e.g., network security, cloud security, system administration)?(Required)

Security is often an afterthought or a reactive task in our daily IT operation.

Security policies exist, but their consistent implementation and enforcement in daily IT operations remains a challenge.

Key security functions like network security, data centre operations and cloud security management are formally recognised and addressed within daily IT operations, with some alignment to CTEM principles.

Security considerations are proactively embedded into daily IT operations, with continuous monitoring of assets, configurations and exposures across all relevant environments (e.g., leveraging cloud governance for cloud assets).

Our daily IT operations are fully aligned with CTEM insights, leveraging advanced technologies (e.g., CSPM, CWPP) and automated workflows to ensure continuous security and reliable system operations across all domains as a shared responsibility.

44. How do your technology operations teams proactively integrate CTEM insights to ensure the secure and reliable operation of IT systems?(Required)

Technology operations primarily focus on system uptime and reactively address security issues.

Technology operations respond to security incidents but are not actively involved in CTEM planning.

Technology operations contribute technical insights to CTEM risk assessments and support the deployment of security tools

Technology operations teams proactively implement security controls and configurations, ensuring secure and reliable IT system operations and providing input on the feasibility and impact of CTEM initiatives.

Security considerations are fully embedded into the daily operations and workflows of technology teams, fostering a shared responsibility culture and continuously improving the overall security posture.

45. To what extent are security teams and technology operations teams collaboratively involved in the continuous monitoring and configuration of cloud environments?(Required)

Cloud security is managed by a separate team, with limited collaboration with technology operations.

Basic cloud security configurations are applied, but continuous monitoring for misconfigurations is limited.

Security teams work with technology operations to implement CSPM (Cloud Security Posture Management) solutions for monitoring.

Cloud governance integrates CTEM to ensure continuous monitoring of cloud assets, configurations and exposures, with active collaboration between security and technology operations.

Technologies like CSPM and CWPP (Cloud Workload Protection Platforms) are leveraged with automated workflows for continuous monitoring and threat detection, with joint responsibility for cloud security posture between security and operations.

Service/Application Development

46. How are security considerations integrated into your software development lifecycle (SDLC)?(Required)

Security is addressed primarily through penetration testing after development.

Some secure coding standards are in place, but not consistently enforced.

Secure coding training and standards are implemented, with security testing throughout the SDLC.

Threat modelling is conducted during the design and development phases.

DevSecOps principles embed CTEM into the SDLC, automating security testing and fostering shared responsibility.

47. What is the level of collaboration between security and development teams?(Required)

Security and development teams operate largely in silos.

The security team provides findings, and the development teams are expected to remediate.

Security requirements are incorporated into application design and development.

Security fixes and features are prioritised based on risk and impact, with security testing throughout the SDLC.

Developers are delegated patch implementation for code remediation, with security teams providing context via tickets.

48. How are secure coding practices and security requirements formally enforced and continuously reviewed throughout your software development lifecycle (SDLC)?(Required)

Secure coding is an optional guideline and security reviews are typically performed only at the end of the SDLC.

Some secure coding standards are in place, but enforcement is inconsistent and reviews are ad-hoc.

Secure coding training and standards are implemented and security testing (e.g., SAST/DAST) is conducted throughout the SDLC.

Security requirements are incorporated into the design and development of applications, with continuous security testing integrated into the CI/CD pipeline and automated checks for secure coding practices.

DevSecOps principles are fully embedded, with automated feedback loops ensuring secure coding practices, threat modelling during design, and continuous security validation throughout the development and deployment lifecycle.

49. To what extent do threat modelling exercises inform the design and architecture of new applications and services to identify and mitigate risks early in the SDLC?(Required)

Threat modelling is not typically performed for new applications, or it's an informal process.

Basic threat modelling is conducted for some applications, but has limited impact on design decisions.

Threat modelling exercises are performed during the design phase of new applications to identify potential threats and vulnerabilities.

Threat modelling is a mandatory step for all new critical applications and its findings directly inform architectural decisions and the implementation of security controls from the outset.

Automated threat modelling tools are integrated into the development pipeline, providing continuous feedback and ensuring security-by-design principles are continuously refined based on evolving threat intelligence and attack patterns.

Domain 3: Governance

This domain covers the organisational structure, governance and oversight necessary for the successful implementation and ongoing management of the CTEM program.

Program Governance

50. What is the current state of your CTEM program's governance structure?(Required)

No formal CTEM program or governance in place.

Initial governance and reporting established, with basic metrics and informal communication.

Formal governance structure and steering committee established, with policies and guidelines in place.

Formal governance structure in place, with respective policies and guidelines, clearly defined and staffed roles and responsibilities, structured as a program of work.

Formal governance structure in place, with respective policies and guidelines. Roles and responsibilities are well defined and staffed in a formal program of work structure. Cross-accountability is established between technology and key business leaders, with continuous learning and improvement.

51. How are CTEM program objectives defined, structured, and aligned with your organisation's broader business goals and risk appetite?(Required)

Our CTEM program objectives are ad-hoc or unclear, with little to no formal alignment to business goals.

Objectives for our CTEM program are defined, but their alignment with overall business goals and risk appetite is limited or inconsistent.

The program objectives, scope, and strategy for our CTEM initiative are formally defined and aligned with clear business goals and the organisation's risk appetite.

CTEM program objectives are systematically integrated into broader strategic planning, with clear KPIs and resource allocation directly tied to achieving specific business outcomes and risk reduction targets.

Our CTEM program objectives continuously adapt to evolving business priorities and the threat landscape, driving enterprise-wide risk appetite adjustments and informing long-term cyber resilience initiatives.

Performance and Escalations

52. How are CTEM program's performance and cyber risks communicated to stakeholders?(Required)

Ad-hoc communication, often reactive to incidents.

Basic reporting mechanisms exist, but transparency and effectiveness are limited.

Regular reporting mechanisms and dashboards are developed for different stakeholders.

Communication standards, reporting structures and escalation paths are formally defined for the CTEM program. Senior leadership and Board are being kept informed.

Transparent reporting structures, communication channels and escalation paths are established for program performance and incidents. Program performance in tracked continuously against agreed goals and reported back to senior leadership and Board.

53. What metrics are used to track and report on CTEM effectiveness?(Required)

Limited metrics, primarily focused on compliance checklists or raw vulnerability counts.

Initial metrics in place, but not consistently tracked or reported for progress.

Key performance indicators (KPIs) and metrics are defined to track program effectiveness.

Metrics are used to report on risk levels, communicate prioritisation decisions and show progress across key areas to stakeholders. Key metrics are incorporated into regular Board reporting.

Executive dashboards translate technical vulnerabilities into business risk narratives, including financial impact projections. Recent trending and overall program performance is well incorporated into ongoing Board reporting.

Steering Committee

54. What is the role of a steering committee in your CTEM program?(Required)

No dedicated steering committee for CTEM.

An existing committee informally reviews some security matters

A formal steering committee is established to provide oversight and strategic guidance for the CTEM program.

The CTEM steering committee reviews program performance and metrics and approves budget and resource allocations.

The CTEM steering committee sets strategic priorities for addressing cyber risks and monitors program progress. Ongoing performance reviews derive lessons learned and areas for improvement across key domains.

55. Who are the key personas involved in the CTEM steering committee or equivalent high-level oversight?(Required)

CISO and IT leadership only.

CISO, CRO and potentially Chief Compliance Officer.

CISO, CRO with Board Chairman/Investors involved in strategic discussions

CISO, CRO, Chief Compliance Officer and other executive and board members.

Executive management team and relevant sub-committees (e.g., Risk, Audit, Technology).

56. What is the formal remit and decision-making authority of your CTEM Steering Committee regarding security strategy, budget and risk acceptance?(Required)

The steering committee (or equivalent) has limited formal authority and primarily serves as an information-sharing forum.

The committee provides general strategic guidance, but concrete decisions on budget or risk acceptance are made elsewhere.

The CTEM steering committee formally reviews and approves the CTEM program objectives, scope, and strategic priorities.

The CTEM steering committee has clear decision-making authority for CTEM budget and resource allocations, major program changes and formal risk acceptance decisions.

The CTEM committee proactively influences enterprise-wide risk appetite, integrates CTEM into broader business strategy and directly drives funding for long-term cyber resilience initiatives.

57. How frequently does the CTEM Steering Committee meet and how are its decisions and program progress communicated to the Board of Directors?(Required)

Meetings are infrequent or ad-hoc and communication to the Board is limited or reactive.

The committee meets periodically and high-level updates are provided to the Board, often as part of broader risk reports.

Regular meetings (e.g., quarterly) are held and the Board receives consistent reports on CTEM program effectiveness and key risk metrics.

The CTEM Steering Committee meets with a defined cadence and its strategic decisions and comprehensive program progress (including ROI and risk reduction) are formally reported to the Board with clear recommendations.

The CTEM Steering Committee meets with a defined cadence with executive dashboards that provide real-time, business-oriented insights from the CTEM program directly to the Board, enabling immediate strategic adjustments and dynamic resource allocation, often driving discussions beyond traditional compliance.

Reporting and Communication

58. How does your organisation communicate the performance and value of its CTEM program to executive leadership and the Board?(Required)

Communication is ad-hoc and primarily reactive to major incidents, with limited visibility into program performance.

Basic communication that includes reports on technical metrics (e.g., vulnerability counts) are occasionally shared, but they lack business context or clear value demonstration.

Regular communication including reports and dashboards to track key CTEM metrics (e.g., Mean Time to Remediate, exposure reduction) tailored to highlight business impact and overall risk posture.

Frequent communication and executive dashboards that provide real-time insights into CTEM effectiveness, including financial impact projections and alignment with strategic business goals and regulatory compliance.

Communication is proactive and transparent across all levels, driving strategic decisions and fostering continuous improvement based on comprehensive, business-centric risk narratives. Executive dashboards provide real-time insights into CTEM effectiveness, including financial impact projections and alignment with strategic business goals and regulatory compliance.

59. How agile is your organisation in adapting its CTEM strategy and security practices in response to changes in the threat landscape or industry regulations?(Required)

Adaptations are reactive and infrequent, primarily driven by major incidents or new compliance mandates.

Basic processes are in place to review new threats or regulations, but strategic adjustments to the CTEM program are limited and slow.

The CTEM program has defined processes for incorporating new threat intelligence and regulatory changes, informing strategic adjustments to security controls and priorities.

Continuous monitoring of the threat landscape and regulatory environment drives proactive refinement of the CTEM strategy, with established feedback loops for rapid adaptation.

The organisation leads industry best practices, with an anticipatory approach that leverages advanced analytics to predict emerging risks and automatically adjust CTEM processes and controls. Continuous refinements employed to adjust to changes in the threat landscape and regulatory environment with established feedback loops for rapid adaptation.

How are CTEM findings, program performance and risk posture communicated to ensure broad stakeholder awareness and drive accountability across the organisation? In what channels and at what frequency are CTEM findings and progress communicated to ensure broad stakeholder awareness and accountability?(Required)

Communication of CTEM findings is informal, ad-hoc and primarily confined within the security team, with limited dissemination to other department.

Basic reports on security posture are shared periodically (e.g., quarterly) via email, but consistent engagement from non-security stakeholders is lacking.

Regular formal meetings (e.g., monthly/fortnightly governance reports) and dashboards are used to communicate CTEM progress and identified risks to key IT and business stakeholders.

Tailored communication plans utilise diverse channels (e.g., executive briefings, departmental workshops, dedicated dashboards) to ensure relevant stakeholders receive actionable and context-specific insights on an agreed-upon cadence.

A highly integrated and automated communication framework ensures real-time transparency of CTEM performance and dynamic risk posture across all organisational levels, driving shared accountability and immediate, informed action.

Domain 4: Vision and Mission

This domain reflects how cybersecurity is integrated into the organisation's overarching vision and strategic goals, focusing on proactive risk management, brand perception and leadership's commitment to continuous cyber resilience. It evaluates the alignment of security initiatives with the organisation's long-term aspirations, beyond mere compliance and how cyber resilience contributes to business enablement and competitive advantage.

Threat-Informed Strategy

61. To what extent does your organisation's cyber security strategy explicitly incorporate a threat-informed approach to risk management?(Required)

Our cyber security strategy is primarily reactive, focusing on known vulnerabilities and compliance checklists, with limited direct incorporation of threat intelligence.

We are starting to integrate basic threat intelligence into our strategy, recognising the limitations of reactive security against sophisticated threats.

Our cyber security strategy is informed by relevant threat intelligence, which helps us prioritise risks and gain better visibility into our attack surface and exposure.

Our strategic planning explicitly uses threat intelligence to proactively reduce risk, optimise security investments based on business impact and anticipate emerging threats relevant to our industry.

Our organisation leads with an anticipatory, threat-informed strategy that leverages advanced analytics and real-time intelligence to continuously adapt security controls and predict emerging risks, driving innovation in cyber resilience.

62. How effectively does your organisation's strategy and practices proactively reduce risk and continuously improve its security posture?(Required)

Our risk reduction efforts are primarily reactive, focusing on responding to incidents after they occur rather than proactively preventing them.

We have some initial efforts to proactively reduce known risks, but a systemic approach to continuous improvement of our security posture is not yet established.

We are actively implementing measures to proactively reduce risk by prioritising vulnerabilities based on threat intelligence and business impact, leading to a visible improvement in our security posture.

Our organisation systematically leverages CTEM principles to continuously identify and mitigate risks, showing a sustained improvement in our security posture and adaptability to the evolving threat landscape.

Proactive risk reduction and continuous improvement are deeply embedded in our organisational strategy, positioning us as a leader in cyber resilience and providing a competitive advantage through sustained security outcomes.

63. What best describes the current involvement of your C-suite executives and Board members in the oversight and strategic direction of cyber risk management?(Required)

C-suite executives and Board members have limited involvement in cyber risk management, primarily receiving high-level, compliance-focused updates.

C-suite members (e.g., CRO, CISO) are informed about cyber risks, but struggle to consistently quantify risk or demonstrate clear ROI to the Board.

The Board and C-suite actively seek greater assurance and transparency on cyber risk management, with regular reporting on security posture and strategy.

C-suite executives and Board members provide strategic guidance, review program performance and metrics, and approve budget allocations for cyber risk management initiatives.

The C-suite and Board proactively influence enterprise-wide risk appetite, integrate cyber resilience (CTEM) into broader business strategy, and directly drive funding for long-term initiatives.

Leadership Buy-in and Alignment

64. To what extent does your organisation view and leverage effective cyber risk management as a strategic driver for enhancing brand perception and customer trust?(Required)

Our organisation primarily views cyber risk management as a compliance burden, with limited direct connection to brand perception or customer trust.

There is a general awareness that strong cyber security can positively impact reputation, but this is not a strategic focus in our brand perception effort.

Our organisation actively communicates its commitment to cyber security to customers and stakeholders, recognising its impact on building trust and reputation.

We strategically leverage effective CTEM to proactively demonstrate commitment to customer data protection and business continuity, actively enhancing brand reputation and competitive advantage.

Cyber resilience, driven by CTEM, is a core and explicit component of our organisation's public vision and marketing strategy, actively differentiating us in the market and attracting customers and investors.

65. To what extent is the pursuit of continuous cyber resilience (via CTEM) explicitly aligned with your organisation's broader strategic vision and mission?(Required)

Cyber resilience is an IT concern, loosely connected to the overall organisational vision.

The organisation acknowledges cyber resilience as important, but it's not explicitly integrated into core strategic documents.

Cyber resilience is recognised as a key enabler for digital transformation and business growth within strategic planning.

The organisation's strategic vision and mission explicitly incorporate continuous cyber resilience (CTEM) as a foundational element for innovation, market leadership, and sustained business success.

CTEM is central to the organisation's ability to operate in a state of continuous cyber resilience, which is directly tied to its long-term competitive advantage, investor confidence, and market positioning.

Business Case and Funding

66. Does your organisation have a formal business case specifically for its CTEM program or equivalent continuous security initiatives?(Required)

No formal business case exists for CTEM; security funding is part of general IT budget.

An informal justification for CTEM exists, but it lacks detailed financial projections or ROI analysis.

A business case has been developed for CTEM, outlining objectives and estimated costs/benefits.

A formal, data-driven business case for CTEM (including projected risk mitigation savings and business friction reduction) was presented to and approved by executive leadership or the Board.

The CTEM business case is continuously updated with empirical data on risk reduction and business value, informing ongoing strategic investment decisions and long-term funding.

67. How is funding allocated for your CTEM program or major continuous security initiatives?(Required)

Funding for security initiatives is primarily reactive and comes from ad-hoc operational budgets (BAU).

Funding is allocated annually as part of the general IT security budget, without specific long-term CTEM planning.

Dedicated funding exists for specific CTEM projects, but a comprehensive, multiyear plan is not in place.

Funding for the CTEM program is specifically allocated through a strategic 3-5 year plan, ensuring sustained investment in continuous cyber resilience capabilities.

CTEM funding is dynamically adjusted based on real-time risk assessments and evolving business priorities, with measurable ROI objectives tied to strategic business outcomes and long-term strategic goals to enhance and maintain cyber resilience.