Article 7: ICT systems, protocols and tools

To meet the article 7: ict systems, protocols and tools requirement, you must run ICT on systems, protocols, and tools that stay current, governed, and demonstrably fit for managing ICT risk, with clear ownership and auditable evidence. Operationalize it by inventorying your ICT tooling stack, setting minimum baselines, enforcing patch/config change control, and proving ongoing effectiveness. (Regulation (EU) 2022/2554, Article 7)

Key takeaways:

• You need a governed, continuously maintained ICT tooling stack, not a one-time “modernization” project. (Regulation (EU) 2022/2554, Article 7)
• Auditors will test traceability: requirement → control → owner → evidence → remediation closure. (Regulation (EU) 2022/2554)
• Fragmented evidence is a common failure mode; centralize it with a control register and readiness drills. (Regulation (EU) 2022/2554)

Article 7 sits in the “foundational hygiene” tier of DORA: your ICT risk framework fails if the underlying systems, protocols, and tools are stale, inconsistently configured, or impossible to evidence under supervisory pressure. The text is short, but the operational expectation is not. Supervisors will expect you to show that the platforms you depend on (identity, endpoint, network, logging, vulnerability management, backup/restore, incident response, third-party connectivity) are kept updated, governed through repeatable processes, and monitored for effective operation. (Regulation (EU) 2022/2554, Article 7)

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing Article 7 is to translate it into a concrete control set with named owners and an evidence map. You are not personally patching servers, but you are accountable for proving that patching, secure configuration, protocol standards, and tool coverage are planned, executed, and tracked to closure. Most teams lose time on two avoidable gaps: unclear accountability across Security/IT/Third-Party/Compliance, and scattered evidence that cannot survive an exam. This page gives you a requirement-level blueprint you can put into motion immediately. (Regulation (EU) 2022/2554)

Regulatory text

Excerpt (provided): “In order to address and manage ICT risk, financial entities shall use and maintain updated ICT systems, protocols and tools that are:” (Regulation (EU) 2022/2554, Article 7)

Operator interpretation:
Your organization must (1) run ICT risk management on top of systems and tooling that are kept current, (2) define and enforce protocol standards and configurations, and (3) be able to prove ongoing maintenance and effectiveness with audit-ready evidence. Article 7 is the “prove your ICT foundation is maintained” requirement that supports everything else in DORA’s ICT risk program. (Regulation (EU) 2022/2554, Article 7)

Plain-English interpretation (what supervisors are looking for)

Article 7 becomes real during an exam when you’re asked questions like: “Show me your patch compliance trend,” “Which tools detect suspicious activity across endpoints and cloud workloads,” or “Which protocols are approved for third-party connections, and how do you enforce them?” If your answer is “it depends,” or the evidence is distributed across tickets, spreadsheets, and tribal knowledge, you will struggle.

Treat Article 7 as four practical expectations:

1. Coverage: You have the right categories of systems and tools to manage ICT risk across your footprint (on-prem, cloud, remote workforce, third parties).
2. Currency: You keep them updated through defined lifecycles (patching, upgrades, deprecation, end-of-life handling).
3. Consistency: You standardize protocols and configurations (secure baselines, encryption standards, logging, access pathways).
4. Proof: You can demonstrate operation over time (metrics, tickets, change records, test results, remediation closure). (Regulation (EU) 2022/2554, Article 7)

Who it applies to (entity and operational context)

Entities: Financial entities within DORA scope should assume Article 7 applies wherever ICT supports regulated activities. (Regulation (EU) 2022/2554)

Operational contexts to scope explicitly:

• Production and customer-facing systems supporting critical or important functions.
• Security tooling (identity, detection/response, vulnerability management, SIEM/logging, backup/restore).
• Network and connectivity controls, including third-party connections, VPNs, APIs, and interconnects.
• Cloud and SaaS administration planes (where misconfiguration risk is common).
• End-user computing (endpoints, mobile, privileged access workstations, remote access).
• Third party–operated components where you rely on a provider’s tools or protocols (you still need governance, contractual hooks, and evidence). (Regulation (EU) 2022/2554)

What you actually need to do (step-by-step)

Step 1: Build an Article 7 control register (requirement → controls → owners → evidence)

Create a single register line item for Article 7 and break it into control statements you can test. Minimum fields:

• Control statement (plain language)
• In-scope assets/tool categories
• Accountable owner (one person), supporting teams (many)
• Frequency/trigger (e.g., “on change,” “continuous,” “scheduled”)
• Evidence artifacts and where stored
• Exception path and risk acceptance authority

This is the fastest way to fix the “no clear accountability” risk factor and to prevent evidence fragmentation. (Regulation (EU) 2022/2554)

Practical note: Daydream is useful here because it can hold the mapping between the legal requirement, your control design, owners, and your evidence checklist in one place, which reduces scramble risk during supervisory requests.

Step 2: Define “updated” in operational terms (policy + standards + minimum baselines)

Write a short standard that defines what “updated” means for your environment, by category:

• OS/platform patching expectations (workstations, servers, network devices)
• Application and middleware upgrades
• Endpoint agent versions (EDR, DLP, device management)
• Encryption and protocol standards (e.g., approved TLS versions/ciphers, SSH configs)
• Logging and time sync requirements
• End-of-life/end-of-support handling (what happens when a product is no longer supported)

Your goal is clarity: teams should be able to say whether something is compliant without a debate. (Regulation (EU) 2022/2554, Article 7)

Step 3: Inventory ICT systems, protocols, and tools in scope (and tie to criticality)

You need an inventory that is “exam-usable,” not just technically correct:

• Systems inventory: CMDB or equivalent view of key infrastructure and applications in scope.
• Tooling inventory: security and operational tools, including versioning and coverage scope.
• Protocol inventory: where protocols matter (remote access, admin access, data in transit, third-party connectivity), list the approved protocols and where they are enforced.

Add two fields that make it compliance-grade:

• Business service / critical or important function mapping
• Third party dependency flag (who operates it; what evidence you can obtain). (Regulation (EU) 2022/2554)

Step 4: Implement lifecycle controls (patch, configuration, and change control with testing)

Operationalize with three linked mechanisms:

• Patch management workflow: intake, prioritization, deployment, exceptions, validation.
• Secure configuration management: baseline templates, drift detection, approvals.
• Change management: changes to critical tooling/protocols require review, testing, and rollback planning.

This is where most programs fail quietly: they have a policy, but exceptions and emergency changes create an uncontrolled “shadow standard.” Treat exceptions as first-class records with expiry and compensating controls. (Regulation (EU) 2022/2554, Article 7)

Step 5: Prove tool effectiveness with monitoring and operational checks

Article 7 is not satisfied by owning tools; you must show they work in practice. Examples of effectiveness checks:

• EDR coverage check across in-scope endpoints and servers
• Central logging ingestion health and retention checks for key sources
• Vulnerability scan coverage and authenticated scanning where applicable
• Backup success plus periodic restore tests for critical systems
• Identity controls: MFA enforcement and privileged access monitoring

Tie each check to an evidence artifact (dashboard export, report, ticket, test record) and an owner. (Regulation (EU) 2022/2554)

Step 6: Establish a regulatory-response workflow for evidence production

Supervisory requests are won or lost in the first days. Create a workflow with:

• Intake channel and triage (what’s requested, by whom, by when)
• Evidence owner assignment and due dates
• Compliance/Legal review for consistency
• Packaging standard (naming conventions, redactions, version control)
• Remediation tracking when gaps are discovered (CAPs with validation evidence)

This maps directly to the practical need to reduce response-time and inconsistency risk. (Regulation (EU) 2022/2554)

Step 7: Run readiness drills and close gaps with corrective actions

Run periodic drills where you simulate an exam request: “Show evidence that ICT systems and tools are updated and governed.” Track:

• Gaps found (missing evidence, unclear owners, outdated baselines)
• Corrective action plan, due date, and validation
• Management reporting and decisions on risk acceptance

Drills convert vague preparedness into repeatable execution. (Regulation (EU) 2022/2554)

Required evidence and artifacts to retain (audit-ready checklist)

Keep evidence in a predictable repository with immutable timestamps where possible. Typical artifacts:

• Article 7 control register entry with owners and evidence map (Regulation (EU) 2022/2554)
• ICT asset/tool inventory extracts (systems, tools, versions, coverage)
• Patch management policy/standard + monthly/quarterly compliance reports
• Change management records for key upgrades and protocol changes
• Secure configuration baselines and drift reports
• Vulnerability management reports and remediation tickets
• Logging/SIEM ingestion health reports and key use cases enabled
• Backup reports and restore test records
• Exception register (patch/config/protocol exceptions) with approvals and expiry
• Readiness drill outputs and corrective action validation

Common exam/audit questions and hangups

Questions you should be ready to answer with evidence:

• “Define ‘updated’ for your critical systems and security tooling. Where is it documented?” (Regulation (EU) 2022/2554, Article 7)
• “Show patch and vulnerability remediation performance for in-scope assets, including exceptions.”
• “Which protocols are approved for third-party connectivity and remote administration, and how do you enforce them?”
• “Prove your monitoring tools cover cloud, endpoints, and core network segments.”
• “Show how you track tool lifecycle risk (end-of-support, deprecated versions).”

Hangups that trigger deeper testing:

• Inventory does not match reality (CMDB drift).
• Evidence is “screenshots in email” with no source-of-truth.
• Exceptions lack expiry or compensating controls.
• Third party components are treated as out-of-scope with no contractual evidence path. (Regulation (EU) 2022/2554)

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating Article 7 as an IT-only patching task.
   Fix: Make it a joint control with Compliance accountability and IT/Security operational ownership; document it in the control register. (Regulation (EU) 2022/2554)

2. Mistake: No definition of “updated.”
   Fix: Publish minimum baselines per asset class and tool category, including end-of-life handling. (Regulation (EU) 2022/2554, Article 7)

3. Mistake: Tool sprawl without coverage clarity.
   Fix: For each tool, document scope, onboarding criteria, and a coverage report that is reviewed on a set cadence.

4. Mistake: Exceptions become permanent.
   Fix: Require expiry dates, compensating controls, and periodic re-approval by a defined authority.

5. Mistake: Evidence is not reproducible.
   Fix: Standardize evidence packages (report exports, ticket IDs, configuration snapshots) and store them centrally with version control. (Regulation (EU) 2022/2554)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Focus on supervisory outcomes: if you cannot show updated systems/tools and consistent protocol governance, you risk findings that cascade into broader DORA program failures (incident detection, response, resilience testing, and third-party oversight all depend on this foundation). (Regulation (EU) 2022/2554)

Practical 30/60/90-day execution plan

Use this as a sprint plan for operationalization. Adjust the scope to your critical or important functions first.

First 30 days (stabilize scope and ownership)

• Stand up the Article 7 control register entry, owners, and evidence map. (Regulation (EU) 2022/2554)
• Define “updated” standards for patches, key protocols, and tool lifecycle.
• Produce an initial inventory snapshot: critical systems, security tools, protocol enforcement points.
• Identify top exceptions (end-of-support systems, missing coverage, unmanaged third-party connections) and open tracked remediation items.

Days 31–60 (make it measurable and repeatable)

• Implement recurring reporting: patch compliance, vulnerability remediation, tool coverage, logging ingestion health.
• Formalize exception workflow with expiry and approval authority.
• Align change management to require testing/rollback for critical tool and protocol changes.
• Create a regulatory-response workflow (intake, assignments, packaging, approvals). (Regulation (EU) 2022/2554)

Days 61–90 (prove operation and close gaps)

• Run a readiness drill: generate a complete evidence pack for Article 7 and time-box the response.
• Validate corrective actions with proof (not “done” emails).
• Report to senior management on remaining risks (legacy systems, third party evidence gaps) and document risk acceptance decisions where needed.
• Put Article 7 into BAU: scheduled reviews, dashboarding, and periodic drills. (Regulation (EU) 2022/2554)

Frequently Asked Questions

What does “updated” mean under Article 7 if DORA doesn’t define it precisely?

Treat “updated” as a defined internal standard by system and tool category, with patching, upgrade, and end-of-life expectations you can measure and evidence. Document it and enforce it through change and exception management. (Regulation (EU) 2022/2554, Article 7)

Do SaaS platforms and cloud services count as “ICT systems, protocols and tools”?

Yes if they support in-scope operations and ICT risk management outcomes. Your control should cover configuration baselines, admin access protocols, logging, and evidence collection, even when the underlying infrastructure is operated by a third party. (Regulation (EU) 2022/2554)

How do I handle third party–managed systems where I can’t patch directly?

Require contractual obligations and evidence rights (reports, attestations, ticket extracts) and track them in your control register and third-party oversight workflow. Where evidence is limited, document compensating controls and risk acceptance. (Regulation (EU) 2022/2554)

What evidence format works best in exams: dashboards, tickets, or policies?

Provide a package that ties all three: the standard (policy), the execution record (tickets/changes), and the outcome (reports/dashboards). Examiners want traceability and repeatability more than screenshots. (Regulation (EU) 2022/2554)

We have multiple tooling stacks across subsidiaries. Do we need one standard?

You need consistent minimum requirements and comparable evidence across the group, even if tools differ. Define group-wide baselines and allow local variation through documented equivalency mappings and an exception process. (Regulation (EU) 2022/2554)

Where does Daydream fit without creating another system of record?

Use Daydream as the compliance-facing layer: map Article 7 to controls, owners, and required evidence, and orchestrate regulatory responses and readiness drills. Keep operational source data in IT/Sec tools, and link evidence outputs back to the control register. (Regulation (EU) 2022/2554)