Question 1 / 24 Governance & Accountability
Has a person responsible for information security risk management been formally appointed?
ISO 27005 requires clear ownership and accountability over the risk management process.
Responsibility is formally documented, confirmed by board resolution, and the person actively fulfils the role
Optimised
A responsible person has been appointed, but the role description is imprecise
Managed
Responsibility is informally shared, but there is no clear owner
Defined
The IT manager handles this when needed — no formal appointment exists
Developing
No one is formally responsible for this topic
Initial
Question 2 / 24 Governance & Accountability
Does the board discuss information security and cyber risks at least quarterly?
Regular board involvement is a sign of maturity and a protection against personal liability.
Regular meetings with a structured agenda, decisions are recorded
Optimised
Once a year in a formal review, ad hoc as needed
Managed
Discussed only when something goes wrong
Defined
The topic is mentioned, but not addressed in a structured way
Developing
The board does not engage with risk topics
Initial
Question 3 / 24 Governance & Accountability
Does the organisation have a current risk management policy approved by the board?
A written policy is a prerequisite for ISO 27005 implementation and the backbone of board accountability.
Written policy, reviewed within the last 12 months, all employees are aware
Optimised
Written policy exists, but has not been reviewed for over 12 months
Managed
Document exists, but actual implementation is not monitored
Defined
Being planned, but not yet approved
Developing
No risk management policy exists
Initial
Question 4 / 24 Governance & Accountability
Has the scope and boundary of risk management been formally documented?
A clear scope prevents key areas from being overlooked and provides an audit baseline.
Clearly defined, covering all business-critical systems, data, and processes
Optimised
Partially defined, key areas are covered
Managed
Verbal agreement exists, not documented in writing
Defined
"All IT" — no more precise scope has been defined
Developing
Scope has never been considered
Initial
Question 5 / 24 Asset & Threat Identification
Does the organisation have an up-to-date list of key information assets (data, systems, processes)?
ISO 27005 requires asset identification and classification as the basis for risk analysis.
A complete, categorised, and criticality-rated asset register, updated regularly
Optimised
A list exists, but does not cover all assets and is not fully up to date
Managed
IT systems are listed, but not data or processes
Defined
There is a rough understanding of assets, but no documented list
Developing
Information assets have not been mapped
Initial
Question 6 / 24 Asset & Threat Identification
Have key threats been systematically identified (cyber attacks, internal errors, supply chain attacks)?
Understanding the threat landscape is necessary for assessing likelihood and selecting controls.
A thorough threat analysis has been conducted, covering cyber, internal, and external threats, kept up to date
Optimised
Key threats have been identified, but the analysis is superficial
Managed
Perceived threats are known, but no structured analysis has been conducted
Defined
Some employees are aware of threats, but they have not been addressed at organisational level
Developing
No threat identification has been carried out
Initial
Question 7 / 24 Asset & Threat Identification
Have key vulnerabilities been analysed (weak configurations, unpatched software, human errors)?
Knowing your vulnerabilities gives you a target for applying controls before an attacker does.
Regular vulnerability scanning and penetration testing, results documented and remediated
Optimised
Vulnerabilities have been identified, but remediation is partially incomplete
Managed
IT team is aware of key vulnerabilities, but no formal analysis exists
Defined
There is general awareness of vulnerabilities, but no formal assessment
Developing
No vulnerability analysis has been conducted
Initial
Question 8 / 24 Asset & Threat Identification
Does the risk identification process involve all key stakeholders (board, IT, business units, partners)?
Diverse participation ensures that significant risks are not overlooked.
A structured process involves everyone — workshops, interviews, feedback cycles
Optimised
Key department heads are involved, but not consistently
Managed
The IT department conducts the analysis independently, others are not involved
Defined
One person assesses risks alone
Developing
Risk identification exists only in individual heads — there is no process
Initial
Question 9 / 24 Risk Analysis & Evaluation
Has the likelihood and potential impact of each significant risk been assessed?
Assessing likelihood and impact is essential for determining risk priority.
Quantitative and qualitative assessment, documented, consistently applied
Optimised
Risks assessed on a qualitative scale, partially documented
Managed
Assessments have been made, but methods are inconsistent
Defined
Some risks have been assessed in general terms, but not systematically
Developing
Risks have not been assessed
Initial
Question 10 / 24 Risk Analysis & Evaluation
Have risk criteria been established — what level of risk is acceptable?
Risk criteria are necessary to prioritise and make defensible decisions.
Clear, measurable risk tolerance criteria, approved by the board
Optimised
General criteria exist, but are not precisely measurable
Managed
A general understanding of "too much risk" exists, but it has not been documented
Defined
Risk tolerance assessments are ad hoc
Developing
No risk criteria exist
Initial
Question 11 / 24 Risk Analysis & Evaluation
Have risks been prioritised and documented in a risk register?
A risk register is the working document of risk management and evidence of governance during an audit.
A complete risk register, prioritised, with owners assigned, regularly updated
Optimised
A risk register exists, but is incomplete and not fully up to date
Managed
Prioritisation is done, but no risk register exists
Defined
Risks are generally known, but not documented
Developing
No risk register exists and no prioritisation takes place
Initial
Question 12 / 24 Risk Analysis & Evaluation
Are risk analysis methods consistent and known to all process participants?
Consistent methodology ensures comparability and reliability of results.
Documented methodology, training completed, consistent application
Optimised
Methods are agreed upon, but not always followed
Managed
Methods vary between participants
Defined
Everyone uses their own approach
Developing
No methodology exists
Initial
Question 13 / 24 Risk Treatment
Has a formal decision been made for each significant risk (mitigate, accept, share, avoid)?
Documented decisions protect board members from personal liability.
A written decision with rationale exists for all significant risks
Optimised
Decisions exist for most risks, some are still pending
Managed
Decisions are made on a case-by-case basis, not systematically
Defined
Reactive decisions — action is taken only when a problem arises
Developing
No formal risk treatment decisions are made
Initial
Question 14 / 24 Risk Treatment
Has a concrete risk treatment action plan been drawn up with deadlines and owners?
An action plan without deadlines and owners is merely a wish list.
A detailed action plan with deadlines, resources, and metrics
Optimised
An action plan exists, but deadlines are vague
Managed
General plans exist, but concrete steps are missing
Defined
Some actions have been planned, but no systematic plan exists
Developing
No action plan exists
Initial
Question 15 / 24 Risk Treatment
Is the effectiveness of implemented security controls measured regularly?
Unmeasured control effectiveness is an assumption, not a fact.
Clear metrics (KPI/KRI), regular reporting to the board
Optimised
Some measurement takes place, but it is not consistent
Managed
Controls are implemented, but effectiveness is not evaluated
Defined
We hope the controls work — no monitoring takes place
Developing
No security controls have been implemented or measured
Initial
Question 16 / 24 Risk Treatment
Has the board formally accepted residual risks (remaining after controls are applied)?
Formal written acceptance protects board members in the event of a later dispute.
Formal written acceptance, regular review
Optimised
Verbal agreement at management level
Managed
Management is aware, but formal acceptance is absent
Defined
The concept of residual risk is familiar, but not applied in practice
Developing
Residual risks have not been considered
Initial
Question 17 / 24 Communication & Consultation
Are employees aware of their role in managing information security risks?
Employees are the most frequent target of attacks — their awareness is the first line of defence.
Regular training, awareness tests, written procedures for all
Optimised
Introductory training for new employees, occasional reminders
Managed
General awareness exists, but no formal training takes place
Defined
Some employees are aware of threats, but there is no organisational-level communication
Developing
Employees have not been informed
Initial
Question 18 / 24 Communication & Consultation
Are external parties (suppliers, cloud services, subcontractors) assessed from a risk perspective?
Supply chain attacks are on the rise — your supplier's security is your security.
All key suppliers undergo regular risk assessment, contracts include security standards
Optimised
Key suppliers have been assessed, smaller ones have not
Managed
Supplier risks are known, but no formal assessment exists
Defined
Supplier contracts contain no security requirements, no assessment takes place
Developing
Supplier risks have never been considered
Initial
Question 19 / 24 Communication & Consultation
Are incidents and risks reported to the board in a structured manner?
A board that is not informed cannot decide — nor defend itself later.
Regular (quarterly) risk report to the board, incidents reported immediately
Optimised
Management is informed of significant events, but the structure is inconsistent
Managed
Notification occurs only for critical incidents
Defined
The board is informed only when problems escalate
Developing
No systematic reporting exists
Initial
Question 20 / 24 Communication & Consultation
Have clients and partners been informed of your data protection practices (GDPR Art. 13/14)?
Failure to fulfil GDPR notification obligations is a regulatory risk in addition to cyber risk.
An up-to-date privacy policy and data processing agreements with all relevant partners
Optimised
Privacy policy exists, data processing agreements with some partners
Managed
Privacy policy on the website, but underlying processes are inadequate
Defined
GDPR requirements are known, but practical implementation is rudimentary
Developing
GDPR obligations have not been substantively fulfilled
Initial
Question 21 / 24 Monitoring & Continuous Improvement
Is the risk management process reviewed as a whole at least once a year?
ISO 27005 requires periodic review — a changed context demands updated risks.
An annual review is scheduled in the calendar, results are documented
Optimised
A review takes place, but irregularly
Managed
Review is done only after a regulatory change or incident
Defined
No review has been conducted yet
Developing
No risk management review takes place
Initial
Question 22 / 24 Monitoring & Continuous Improvement
Is the risk matrix updated when significant changes occur (new service, system, or legislation)?
A changed business environment brings new risks — an outdated risk picture is misleading.
The change management process automatically triggers a risk review
Optimised
A general risk review is conducted upon changes, but not always systematically
Managed
Major changes trigger a review, minor ones do not
Defined
The risk matrix is updated only after incidents
Developing
The risk matrix is never updated
Initial
Question 23 / 24 Monitoring & Continuous Improvement
Is the effectiveness of risk management measured using specific metrics (KPI/KRI)?
What cannot be measured cannot be managed — metrics give the board an evidence-based picture.
Clearly defined KPI/KRI metrics, regular measurement and reporting
Optimised
Some metrics exist, but measurement is inconsistent
Managed
Measurement has been discussed, but no formal system exists
Defined
We rely on subjective assessment, not data
Developing
Question 24 / 24 Monitoring & Continuous Improvement
Does the organisation have a functioning incident registration and post-incident analysis process?
Learning from incidents is the only way to genuinely improve maturity.
All incidents are registered, analysed, and lessons learned are applied to process improvement
Optimised
Major incidents are registered, but post-incident analysis is inconsistent
Managed
Large incidents are documented, smaller ones are not
Defined
Incidents are responded to, but not documented or analysed
Developing
No incident register exists and no post-incident analysis takes place
Initial
InitialDevelopingDefinedManagedOptimised
Domain overview
DomainScoreLevel
Governance & Accountability––
Asset & Threat Identification––
Risk Analysis & Evaluation––
Risk Treatment––
Communication & Consultation––
Monitoring & Continuous Improvement––
Gaps & areas for improvement
–
K1: Has a person responsible for information security risk management been formally appointed?
–
–
K2: Does the board discuss information security and cyber risks at least quarterly?
–
–
K3: Does the organisation have a current risk management policy approved by the board?
–
–
K4: Has the scope and boundary of risk management been formally documented?
–
–
K5: Does the organisation have an up-to-date list of key information assets (data, systems, processes)?
–
–
K6: Have key threats been systematically identified (cyber attacks, internal errors, supply chain attacks)?
–
–
K7: Have key vulnerabilities been analysed (weak configurations, unpatched software, human errors)?
–
–
K8: Does the risk identification process involve all key stakeholders (board, IT, business units, partners)?
–
–
K9: Has the likelihood and potential impact of each significant risk been assessed?
–
–
K10: Have risk criteria been established — what level of risk is acceptable?
–
–
K11: Have risks been prioritised and documented in a risk register?
–
–
K12: Are risk analysis methods consistent and known to all process participants?
–
–
K13: Has a formal decision been made for each significant risk (mitigate, accept, share, avoid)?
–
–
K14: Has a concrete risk treatment action plan been drawn up with deadlines and owners?
–
–
K15: Is the effectiveness of implemented security controls measured regularly?
–
–
K16: Has the board formally accepted residual risks (remaining after controls are applied)?
–
–
K17: Are employees aware of their role in managing information security risks?
–
–
K18: Are external parties (suppliers, cloud services, subcontractors) assessed from a risk perspective?
–
–
K19: Are incidents and risks reported to the board in a structured manner?
–
–
K20: Have clients and partners been informed of your data protection practices (GDPR Art. 13/14)?
–
–
K21: Is the risk management process reviewed as a whole at least once a year?
–
–
K22: Is the risk matrix updated when significant changes occur (new service, system, or legislation)?
–
–
K23: Is the effectiveness of risk management measured using specific metrics (KPI/KRI)?
–
–
K24: Does the organisation have a functioning incident registration and post-incident analysis process?
–