grcskills
Menu

ICT risk framework check

Use this skill when a bank, payment or e-money institution, investment firm, insurer, crypto-asset service provider or other financial entity in scope of DORA needs to know whether its ICT risk management setup holds up, or when someone asks "DORA gap analysis", "are we DORA compliant on ICT risk", "check our ICT risk management framework", "prepare for the supervisor's DORA review", "does our ISO 27001 ISMS cover DORA" or "audit our Article 6 framework". Confirms the entity type and whether the simplified regime applies, maps the entity's own documents and records against the ICT risk management articles, and writes a gap list with owners, evidence and priorities.

RiskDORA

Use this for one legal entity at a time; groups run it per entity, then compare. You get two files in a new folder, ./ict-risk-framework-check/: a spreadsheet you can open in Excel with one row per DORA topic, showing which document or record covers it, the gap, its severity and a proposed owner (gap-register.csv), and a short summary for the management body with the gaps that matter most and the decisions only it can take (summary.md). This skill drafts for a human to review and sign; this skill never marks a control effective. The check reads documents and records; it is not a legal opinion, and it does not decide what the competent authority will accept.

Inputs to gather

Read the entity's licence or authorisation type, group structure, the ICT risk management framework document (if one exists), the digital operational resilience strategy, the ICT and information security policies, the asset and ICT service inventories, the business continuity and backup documents, incident records, internal audit reports on ICT, management body minutes that discuss ICT risk, and any existing security certification scope. Ask the reader: which entity type and competent authority apply, whether the entity is a microenterprise, and whether any supervisor letter or inspection is open.

Step 1: settle applicability and proportionality

Confirm the entity type falls within DORA's scope (Article 2) and record it. DORA has applied since 17 January 2025 (Article 64), so every gap is a live obligation to remediate, not preparation. Check whether the entity is one of the categories listed for the simplified ICT risk management framework (Article 16); if it is, check against that regime, not the full one. Size alone does not move an entity there: a microenterprise stays under the full framework, with lighter duties in some articles (for example periodic rather than yearly review of the framework, no separate control function or internal audit of it). Note proportionality (Article 4): size, risk profile and the nature of services shape how much is expected. Where unclear, run a framework lookup or mark it for the entity's legal function. The regulatory technical standards on the ICT risk management framework (Commission Delegated Regulation (EU) 2024/1774) carry the operative detail for protection, detection and continuity; run a framework lookup for that detail rather than inferring it.

Step 2: map evidence article by article

Build the gap spreadsheet (gap-register.csv) with one row per topic below, and columns: article, topic, the entity's document or record that covers it, evidence it operates, cadence and date last done, gap, severity, proposed owner, proposed action.

  • Article 5: the management body's role in ICT risk (approval, oversight, budget, its own ICT knowledge and training).
  • Article 6: the documented framework, its review cycle and review after major incidents, the control function and its independence, internal audit of the framework, the resilience strategy.
  • Article 7: fitness of ICT systems, protocols and tools.
  • Article 8: identification and classification of business functions, information and ICT assets, dependencies, and legacy systems.
  • Article 9: protection and prevention measures.
  • Article 10: detection of anomalous activity.
  • Articles 11 and 12: response and recovery, ICT business continuity, backup and restoration.
  • Article 13: learning from incidents and testing, awareness and training.
  • Article 14: crisis communication.

For each row, prefer a record over a document: minutes showing the management body approved and discussed the framework beat a policy that says it will. Several duties recur, and supervisors test the rhythm, not one past occurrence: the yearly framework review and review after major incidents (Article 6(5)), the yearly legacy system assessment (Article 8(7)), yearly continuity plan testing (Article 11(6)), and the yearly report of senior ICT staff to the management body (Article 13(5)). Add three closing rows marked "assessed by its own check": the register of information (Article 28), incident reporting (Articles 17 to 23) and resilience testing (Articles 24 to 27), so the summary shows the whole perimeter.

Step 3: reuse what already exists

Where the entity runs a certified security management system, map each of its relevant documents and records to the rows. Mark where it covers the topic fully, partly or not at all. Typical partial or missing areas are the management body's direct accountability and training, the resilience strategy and stated risk tolerance, the independence of the ICT risk control function, legacy system assessment, and the link to the ICT third-party register (assessed with its own check). Never assume a certificate closes a row; check the scope and the records.

Step 4: grade and prioritise

Grade each gap: missing (no document, no practice), paper only (document, no evidence it runs), partial (runs, but not across the scope or not on cadence), covered. Prioritise by supervisory visibility and by risk: management body gaps and missing frameworks first, because everything else hangs on them.

Step 5: summarise for the management body

In the management body summary (summary.md): entity, regime applied, count of gaps by grade, the five gaps that would matter most in a supervisory review, proposed owners, and the decisions the management body itself has to take.

What good looks like

  • The applicability call is written down with its reason before any gap is listed. A full-regime gap list for an entity under the simplified regime wastes months.
  • The common mistake is a mapping that marks every article "covered" because the security policy mentions the topic. The tell: no row cites a record, minutes or test result, only policy section numbers.
  • Management body evidence is real: agendas, minutes, training attendance. Supervisors look there first.
  • The gap list is short enough to plan: 15 to 40 rows for most mid-sized entities, each with an owner and action.

Framework lookups

If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-ict-risk-framework-check

Rules

  • MUST record the entity type and the regime applied, with the reason, before listing gaps.
  • MUST cite a document or record for every row marked covered or partial.
  • MUST write outputs only inside ./ict-risk-framework-check/ and ask before overwriting an existing file.
  • NEVER present the gap list as a legal opinion or as the competent authority's view.
  • NEVER mark a row covered on the strength of a certificate without checking its scope and records.
  • NEVER contact a supervisor, auditor or provider on the entity's behalf.