Article 9 DORA: protection and prevention requirements

What DORA Article 9 asks for and why it is hard to prove

Article 9 requires a financial entity to continuously monitor and control the security and functioning of its ICT systems, and to run ICT security policies, procedures, protocols and tools that keep those systems resilient and available. The bar is highest for systems supporting critical or important functions, and it extends to protecting data at rest, in use and in transit. Article 9(4) then names the protective policies a supervisor will look for: a documented information security policy, a risk-based network and infrastructure structure that can isolate affected assets during a cyber-attack, access limited to what approved activity requires, strong authentication, cryptographic key protection driven by data classification, documented change management, and patch and update policies. The network design must also allow connections to be severed or segmented quickly to contain contagion. *Delegated Regulation (EU) 2024/1774* turns these duties into operational detail, including automated vulnerability scanning of in-scope assets at least weekly, firewall rule verification at least every six months for systems supporting critical or important functions, and access rights reviews at the same six-month interval for those systems and at least yearly for others.

The difficulty is rarely the policy. Most entities can produce a policy set. A supervisor will ask whether the controls operated on every day of the review period, and that question is answered by records, not documents. For each named policy, ask who owns it, which system enforces it, and what log, ticket, scan report or approval proves the enforcement happened on a given date. A firewall rule set reviewed once is not evidence of six-monthly verification. A patch policy that names a seven-day window is not evidence of patching unless the asset inventory, scan results and change records line up. Confirm with your competent authority how it expects continuous monitoring to be demonstrated, and check whether your own sector guidance adds frequencies beyond the regulation.

Start the gap review with the three evidence streams that are most often missing: scan and monitoring output retained over time, access review sign-offs with the removals they produced, and change records that show testing and verification before go-live. Open-source platforms can generate much of this material when they are configured to retain it. OPNsense can log each rule match for review in its live log view, authentik's authenticator validation stage shows which second factors are enrolled and checked at login, and FreeIPA supports TOTP and HOTP tokens for two-factor authentication. Coraza, which is compatible with OWASP Core Rule Set rulesets, can add web attack protection in front of applications. None of these tools produces an assessment on its own. The entity still owns the policies, the frequencies and the sign-offs, and the independent assessor decides whether the evidence is sufficient.

Which systems, data and teams Article 9 reaches

Article 9 applies to every ICT system an entity runs, but the depth of control depends on which systems support critical or important functions. The cards below cover the scoping decisions that change the work and the review cadence that follows from them. Each decision should be written down before controls are configured, because it determines which systems fall under the stricter 2024/1774 review intervals.

Systems supporting critical or important functions

This is the scoping decision with the largest effect on workload. Article 9 asks for continuous monitoring and control of systems that support critical or important functions, and Delegated Regulation 2024/1774 attaches shorter review intervals to them. Check that the business function map from the asset inventory is current, and record for each system which function it supports and why. Systems without a recorded function usually end up in the wrong review cycle.

Data at rest, in use and in transit

Article 9 requires protection of data in all three states, so scope must cover storage volumes, databases, backups, application memory and every network path that carries data. Map where each data class lives and which encryption mechanism protects it. Encryption choices should follow the data classification and ICT risk assessment, so a field-level decision for payment or identity data may differ from a volume-level decision for logs.

Network and infrastructure zones

Article 9 requires a risk-based network structure in which connections can be severed or segmented quickly to stop contagion between interconnected financial processes. Define zones by function and sensitivity, then document the firewall policies between them. OPNsense rules can be reviewed against aliases for each zone, and Delegated Regulation 2024/1774 requires firewall rule verification at least every six months for systems supporting critical or important functions. Each zone boundary is a separate review item.

Privileged and service accounts

Human administrators are only part of the access picture. Service accounts, automation identities, break-glass accounts and vendor support accounts often hold broader rights than any staff member and are less visible in identity reviews. Inventory each account, its owner, its rights and its authentication method. Access rights review intervals under 2024/1774 differ by system criticality, so the scope decision also determines how often each account must be re-approved.

Third-party hosted components

Scope does not stop at systems the entity operates directly. Managed databases, hosted identity services, SaaS monitoring and vendor-maintained appliances process or protect financial data, and Article 9 controls still apply to the parts the entity configures or relies on. Confirm in each contract which party patches, logs, backs up and manages keys, and record the gaps. Self-hosted open-source components keep these responsibilities inside the entity, which makes the boundary easier to document.

Teams that own each control

Article 9 controls cross several teams: network engineering, identity administration, application development, platform operations and security. Assign a named owner to each scoped system and each control family, and state who approves changes to firewall rules, access grants and encryption keys. Unowned controls are the most common reason evidence is missing at review. Confirm that owners have the access and time to produce records on request.

How continuous monitoring and control shows up in practice

Article 9(1) and (2) asks for monitoring that runs all the time, not a snapshot taken at audit time. The entity must continuously monitor and control the security and functioning of its ICT systems, and keep its protective tools working so that systems stay resilient and available, with priority on those supporting critical or important functions. Periodic penetration tests and annual control reviews still have a place, but they answer a different question. A test shows what an attacker could do on the day it was run. Continuous monitoring shows whether the controls are still in the state the policy describes, and whether anyone notices when they drift. Assessors will ask for both, and they will check whether the recurring activity is written down, owned by a named role and produces records that someone reviews.

Delegated Regulation (EU) 2024/1774 turns this into recurring signals that an assessor can sample. For ICT assets supporting critical or important functions, automated vulnerability scanning must run at least weekly (Article 10), firewall rule verification must happen at least every six months (Article 13), and access rights must be reviewed at least every six months for those systems and at least yearly for others (Article 21). The practical decision for the reader is the scope: which systems are tagged as supporting critical or important functions, because that tag sets the frequency. Confirm that the asset inventory carries the tag, that scan schedules and firewall review dates are derived from it, and that the scan reports, rule review sign-offs and access recertifications are retained as dated evidence. Detection of live attacks and anomalies is covered under Article 10, so this section treats the monitoring here as the control loop that keeps the protective configuration itself honest.

How an assessor tests Article 9 protection controls

This table compares, for each Article 9 protection element, how a competent authority or independent assessor typically tests it, what evidence they ask for, and where organizations most often fall short. Read each row as a checklist: a policy alone rarely passes, so look for the operating records behind it. The main takeaway is that assessors test whether controls run in practice, not only whether they are written down.

Element	Test approach	Evidence requested	Common findings
Information security policy	Check that a documented policy exists, is approved by the management body, covers the ICT security areas in Delegated Regulation (EU) 2024/1774, and is reviewed at a defined interval.	Approved policy version history, approval records, review minutes, and mapping of each policy section to an owning procedure.	Policy exists but no procedures, owners or review dates; policy text does not match how systems are actually run.
Network segmentation and automated isolation	Trace the network design, confirm critical or important functions sit in separate zones, and test whether affected segments can be cut off quickly during an attack.	Current network diagrams, zone and firewall rule exports, segmentation test results, and records of isolation procedures being exercised.	Flat networks behind a single perimeter; firewall rules never reviewed; isolation documented but never tested.
Least-privilege access	Sample accounts and roles, compare granted rights with approved job functions, and check that access is reviewed at the frequency the delegated regulation sets for critical or important functions.	Access request and approval tickets, role definitions, periodic access review sign-offs, and leaver deprovisioning logs.	Standing administrator rights, shared accounts, and access reviews signed off without removing any rights.
Strong authentication	Verify that multi-factor authentication applies to privileged and remote access, that factors are based on recognized standards, and that recovery paths do not weaken them.	Authentication configuration exports, enrollment records, exception register with approvals, and recovery code handling procedure.	MFA missing on admin consoles or VPN; exceptions granted without expiry; SMS or static codes used without a documented risk decision.
Cryptographic key protection	Review how encryption is chosen against data classification and risk assessment, where keys are generated and stored, and who can use them.	Data classification register, encryption standard, key inventory, key rotation and custody records, and access logs for key stores.	Keys stored alongside encrypted data; no key inventory; encryption applied inconsistently across data at rest, in use and in transit.
Change management	Select a sample of production changes and trace each one through recording, testing, assessment, approval, implementation and post-change verification.	Change tickets, test evidence, risk assessments, approval records, implementation logs, and post-implementation review notes.	Emergency changes without later review; changes made outside the ticketing tool; approvals given after implementation.
Patching and vulnerability management	Check that patch and update policies are documented, that automated vulnerability scans run at the frequency the delegated regulation sets, and that findings are tracked to closure.	Scan reports and schedules, patch records by asset, exception approvals for delayed patches, and remediation tracking.	Scans run once and not repeated; patch backlogs with no risk acceptance; unsupported systems still in production.

Implementing Article 9 in sequence

The order below turns Article 9 from a list of protective duties into a set of documented controls, each with evidence an assessor can test. Each step depends on the output of the one before it, so the sequence is worth following in order.

Classify systems by critical or important function
Start from the ICT asset inventory and mark every system that supports a critical or important function, along with the systems it depends on. The owner of each business function confirms the classification, and the ICT risk function reviews it. This step is done when every in-scope system has a recorded classification, a named owner and a list of dependencies. The list sets the depth of every later control, because Delegated Regulation (EU) 2024/1774 applies its strictest frequencies to systems supporting such functions.
Approve the information security policy
Draft the documented information security policy with the risk owners, then ask the management body to approve it. The policy should name the protective areas Article 9 covers and point to the supporting procedures for each. The output is a signed, dated policy with a review date and a distribution record. Ask your auditor which version and approval evidence they expect, since assessors test whether the board actually approved the policy rather than whether a draft exists.
Define network segmentation and access zones
Map the network into zones based on the classification from step one, and decide which flows may cross each boundary. Configure the boundary controls, such as a stateful packet filter, so that rules are grouped by aliases and every rule match can be logged. An isolation mechanism should be able to cut affected segments during an attack, as Article 9(4) describes. The output is a zone diagram, a rule set with a documented owner for each rule, and a test showing that a segment can be severed without taking down unrelated systems.
Enforce least-privilege access and strong authentication
Grant each identity only the access that an approved activity requires, and tie each grant to a named owner and business reason. Require strong authentication for administrative and remote access, with second factors that match the standards your risk assessment selects. Schedule access reviews on the cadence Delegated Regulation (EU) 2024/1774 sets: at least every six months for systems supporting critical or important functions and at least yearly for others. The output is an access register, the authentication configuration and the first signed review record.
Set key handling by data classification
Using the data classification and the ICT risk assessment, decide which data must be encrypted at rest, in use and in transit, and which encryption algorithms and key lengths each category needs. Document who generates, stores, rotates and revokes keys, and separate key custody from the systems that use the keys where your architecture allows. The output is an encryption and key management standard, a key inventory and evidence of at least one rotation or revocation test. Confirm the specific cryptographic requirements with your competent authority and your own assessor.
Document the change and patch procedure
Write a risk-based change procedure that requires every change to be recorded, tested, assessed, approved, implemented and verified. Add a patch and update policy that states how vulnerabilities are scanned and prioritized, and how patch deadlines follow criticality. Delegated Regulation (EU) 2024/1774 requires automated vulnerability scanning of in-scope assets at least weekly. The output is the procedure, a change log sample showing each stage, and scan reports that link to tracked remediation tickets.
Schedule the recurring reviews
Set a calendar that covers firewall rule verification, access rights reviews, vulnerability scanning, policy reviews and the review of key and change records. Assign an owner to each recurring task and define what the output of each review looks like. Firewall rules for systems supporting critical or important functions must be verified at least every six months under the 2024/1774 Regulation. The output is a control calendar with completed review records, which becomes the core of your evidence file for supervisory inspection.

Which open-source tools support each protective control

Article 9(4) expects a risk-based network and infrastructure management structure, with segmentation and the ability to isolate affected assets. OPNsense, a stateful packet filter, can express that design through rules that pass, block or reject traffic by source, destination, port and protocol. Its aliases let teams group addresses by system or function, so rules read in terms of business services rather than individual hosts.

Rule exports: The configuration can be exported and kept under version control, which gives assessors a dated record of the rule base.
Rule match logging: Logging each rule match can show which segments were reached and which traffic was denied during a review period.
Aliases for segmentation: Address groups tied to critical or important functions make it easier to show that those zones are restricted.
Verification cadence: Delegated Regulation (EU) 2024/1774 expects firewall rules for systems supporting critical or important functions to be verified at least every six months, so keep dated review records.
Licence: OPNsense is licensed under BSD-2-Clause, which permits commercial use and modification with attribution and notice retained.

Confirm in your own environment whether your OPNsense version and deployment model provide the log retention, export and alias features you plan to rely on.

Evidence that passes an Article 9 review

An assessor looking at Article 9 does not accept a policy that exists only on paper. Each artifact below must show that the control was designed, operated and reviewed over time, with dates and sign-offs. The cards cover the records that connect the protective policies to working systems.

Approved information security policy

The documented information security policy is the anchor document Article 9(4)(a) requires. Keep the approved version, the approving body, the review date and the change log in one controlled location. Check that the policy names the scope, the owner of each control area and the link to the ICT risk management framework. An assessor will compare the policy against the detailed requirements in Delegated Regulation (EU) 2024/1774, so each section should map to a named procedure rather than a general statement.

Network diagrams and firewall rule exports

Current network diagrams showing segments, trust zones and the points where systems supporting critical or important functions can be isolated fulfil the segmentation requirement in Article 9(4). Pair them with exports of the firewall rule set from the platform, such as OPNsense aliases and rules with logging enabled. Keep the verification record for each rule review, showing who checked the rules, what was removed or justified, and the date. Under 2024/1774, firewall rules for these systems must be verified at least every 6 months, so the record should show that cadence was met.

Access review sign-offs

Access reviews show that least-privilege rules are enforced over time, not only designed. Delegated Regulation (EU) 2024/1774 requires access rights to be reviewed at least every 6 months for systems supporting critical or important functions and at least yearly for others. Keep exported group memberships from the identity platform, the reviewer's signed decision for each account, and the removals made after review. Ask whether service accounts and privileged roles are included, since assessors often sample them first.

Authentication configuration records

Strong authentication under Article 9(4)(d) is evidenced by configuration, not by a statement that MFA is in use. Keep exports of the enabled authenticator stages, the second factors permitted for each user group, and the recovery code policy. For example, an authentik authenticator validation stage shows which factors such as TOTP, WebAuthn or passkeys are accepted at login. Record any exceptions, their approval and their expiry date, and confirm that FreeIPA or other directory settings match the documented policy.

Cryptographic key inventory and rotation records

Article 9(4)(d) requires protection of cryptographic keys, with encryption driven by data classification and risk assessment. The evidence is a key inventory listing each key or certificate, its purpose, the data it protects, its owner, storage location and expiry date. Attach the rotation log and the record of any key compromise response. Confirm that the classification scheme used to choose encryption strength is the same one referenced in the asset inventory, because assessors will test that link.

Change tickets with test and approval trails

Article 9(4)(e) requires documented, risk-based change management so that every change is recorded, tested, assessed, approved, implemented and verified. A useful sample contains the request, the risk assessment, the test result, the approver, the deployment record and the post-change verification. Ask whether emergency changes follow a separate, documented path with after-the-fact review. Gaps between the ticket system and the actual deployment history are a common reason assessors open further sampling.

Vulnerability scans and patch records

Patch and update policies under Article 9(4)(f) become evidence through scan outputs and patch logs. Delegated Regulation (EU) 2024/1774 requires automated vulnerability scanning of ICT assets supporting critical or important functions at least weekly. Keep scan reports, the triage decision for each finding, the patch or compensating control applied, and the date of closure. Keep the scanner's asset list aligned with the inventory so that unscanned systems are visible rather than silently excluded.

What meeting Article 9 costs in money and effort

This table breaks down the main cost components of meeting Article 9 protection and prevention, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Read it as a list of questions to put to your own estate and to any quote you receive, since no supplied figures set the amounts.

Cost component	Who is paid and for what	One-time or recurring, and main drivers
Tooling and licences	Software vendors for commercial firewalls, identity, scanning and monitoring products	Usually recurring. Driven by user count, endpoint count and the number of protected systems. Self-hosted open-source alternatives can remove most licence spend, but support subscriptions may still apply.
Segmentation and network design	Internal network engineers, or an implementation partner, to design zones and rule sets	Mostly one-time for the design, then recurring for rule maintenance. Driven by estate size, the number of critical or important functions and how interconnected financial processes are.
Strong authentication rollout	Identity engineers to deploy multi-factor authentication, enrol users and integrate applications	Mostly one-time for integration, then recurring for token lifecycle and helpdesk work. Driven by the number of applications, legacy systems without modern protocols and the number of users.
Least-privilege access reviews	Access owners and security staff who review rights on the cadence Delegated Regulation (EU) 2024/1774 sets	Recurring. Driven by the number of critical systems, role complexity and how well identity records are kept current.
Change management and patching process	Platform teams to record, test, approve and verify changes; staff to run patch cycles	Process setup is one-time, but effort recurs with every change and patch. Driven by release frequency and the proportion of legacy systems that need manual handling.
Evidence upkeep	Compliance and security staff to collect, date and file records that show each control operated	Recurring. Driven by the number of controls, how automated logging and ticketing are, and how often assessors or supervisors request samples.
External penetration or configuration review	Independent testers or assessors engaged by the organization	Recurring on a schedule the organization sets. Driven by scope, the number of internet-facing services and whether the test is repeated after major changes. Ask for the written scope before comparing quotes.
Supervisor or auditor sampling	Staff time to answer requests and produce samples; fees only if an external auditor is engaged for the work	Recurring at each assessment cycle. Driven by the number of systems in scope and how quickly evidence can be retrieved. Confirm with your competent authority how it will sample.

Where Article 9 programmes usually fall short

Most Article 9 gaps are not missing policies. They are controls that were designed once and never checked again, or that exist on paper but not in the network, identity store or change pipeline. The cards below cover the gaps assessors most often find and the closure action that produces evidence for each.

Flat networks behind one perimeter

A single firewall at the edge with open traffic between internal zones means one compromised workstation can reach core systems. Article 9(4) expects a network designed so it can be segmented or severed quickly to stop contagion, especially between interconnected financial processes. Check whether critical or important functions sit in their own zones with documented allowed flows, and whether isolation can be triggered without an outage of unrelated services.

Shared administrator accounts

Shared privileged accounts make it impossible to attribute an action to a person, which undermines both access control and incident investigation. Article 9(4)(c) requires access limited to what legitimate, approved activities need. Closure means named administrator identities, a documented approval for each privileged grant, and a break-glass account that is sealed, logged and reviewed after use.

Firewall rules never re-verified

Rules accumulate through emergency changes and project exceptions, and few teams remove them afterwards. Delegated Regulation (EU) 2024/1774 expects firewall rule verification at least every six months for systems supporting critical or important functions. Ask for the last verification record, the owner of each rule and the logged match counts that show which rules are still used.

Change records without test or approval

Change tickets that show only a description and a close date do not show that a change was tested, assessed, approved and verified, which are the steps Article 9(4)(e) names. Examine a sample of production changes from the last quarter and trace each one to a test result, an approver who is not the implementer, and a post-implementation check. Gaps here are usually process gaps, not tooling gaps.

Key material stored with protected data

Encryption keys kept on the same volume, in the same backup set or in the same configuration repository as the data they protect offer little protection once that store is copied. Article 9(4)(d) calls for key protection with encryption driven by data classification and risk assessment. Confirm where each key class lives, who can export it, and whether a restore from backup would also expose the keys.

Patch policies without measured timelines

A patch policy that says updates are applied promptly cannot be tested against a timeline, so auditors ask for the data behind it. Delegated Regulation (EU) 2024/1774 expects automated vulnerability scanning of critical or important assets at least weekly. Closure means fixed remediation windows by severity, a dashboard of open items against those windows and documented exceptions with an accountable owner.

Who does what in an Article 9 programme

The financial entity owns Article 9. Its management body remains responsible for ICT risk under the governance requirements, and its own staff decide which controls apply, how risk is accepted, and who approves policies, access and changes. Nothing in an implementation project transfers that accountability to a vendor or consultant. Inside the entity, the security function, the platform or IT operations team and the owners of critical or important functions each carry specific duties under the policy.

Policy ownership: Approving the information security policy and the supporting ICT security policies, procedures and protocols required under Article 9 and the related delegated regulation.
Risk decisions: Deciding the risk-based network segmentation design, the strength of authentication, the key protection approach and the patch timelines, and recording any accepted residual risk.
Operational control: Running the change approval board, performing access reviews and reviewing firewall rules on the cadences the delegated regulation sets.
Evidence custody: Keeping logs, approvals, test results and review records in a form the entity can produce on request.
Third-party oversight: Retaining responsibility for any service provider that operates part of the protective stack.

Before engaging any partner, confirm internally who signs each policy, who approves each exception, and who would answer a supervisor's questions about a specific control.

Article 9 questions buyers ask before hiring help

Can we meet DORA Article 9 with our own team?

Yes, in principle. DORA places the duty on the financial entity itself, and nothing in Article 9 requires an outside firm. The practical question is whether your team has the capacity and the skills to design the policies, run the monitoring and network controls, keep change and patch records, and produce evidence on a steady schedule. Many entities keep ownership of policy and risk decisions in-house and bring in a partner only for the build or the evidence work. Be honest about how many people will run these controls each week, because the work recurs for as long as the systems run. A partner can prepare systems and evidence, but the entity still owns the controls and the supervisor will hold the entity responsible.

How long does Article 9 work take, and what drives the timeline?

The timeline depends mostly on the number of in-scope systems, how mature your current controls are, and how much of the network and identity design must change. Systems supporting critical or important functions carry the heaviest load, so inventories and classification done under Article 8 shorten the work. Other drivers include whether authentication must move to a new platform, how many firewall rule sets exist, and how many change and patch processes are informal today. No duration is stated here because none is supplied for this topic. Ask any partner for a written scope that breaks the work into phases with named deliverables, and confirm the dependencies on your own change calendar before work starts.

What must our team supply before a partner can start?

A partner needs access to the environment and people who can explain it. Typically this includes the current asset and system inventory, network diagrams and firewall rule exports, the identity sources and existing second-factor arrangements, cryptographic key and certificate records, and the change and patch procedures your teams actually follow. You will also need a named owner who can approve policy text and decide on risk acceptance, and a change window for any production adjustment. Ask the partner to list these inputs in the written scope, with the person responsible for each, so gaps appear before the schedule is set rather than during testing.

Do open-source tools satisfy the Article 9 requirements?

A tool does not satisfy a requirement on its own. DORA asks for outcomes such as documented policies, controlled network segmentation, strong authentication and recorded change, and the tool is only one way to produce them. Open-source components can cover parts of this work. For example, OPNsense is a stateful packet filter whose rules can be logged for review, Coraza is a web application firewall compatible with ModSecurity SecLang rulesets and the OWASP Core Rule Set, authentik can validate TOTP, WebAuthn and FIDO2 factors during login, and FreeIPA supports HOTP and TOTP tokens. Confirm each tool's features against your own design and your supervisor's expectations before relying on it, and check the licence terms with your legal team.

How often must reviews run under Delegated Regulation 2024/1774?

For systems supporting critical or important functions, Delegated Regulation (EU) 2024/1774 requires automated vulnerability scanning at least weekly under Article 10, firewall rule verification at least every 6 months under Article 13, and access rights review at least every 6 months under Article 21. For other systems, the access rights review interval is at least yearly. Build these cadences into your control calendar with an owner and a stored record for each run. Confirm the classification of each system with your own risk assessment, because the stricter cycle applies only to systems that support critical or important functions.

What should a partner's written scope include for Article 9?

A useful written scope names the systems in and out of scope, and states which functions they support. It should list each Article 9 area covered, including the information security policy, network segmentation, least-privilege access, strong authentication, cryptographic key protection, change management and patching. For each area it should state the deliverables, such as policy drafts, configuration baselines, test records and evidence packs, and who approves them. It should also set out the review cadence the partner will configure, the handover and training for your staff, the assumptions about your environment, and the process for changes to scope. Note that the partner prepares systems and evidence, while the entity owns the controls and independent assessors or supervisors judge them.

What recurring costs follow an Article 9 implementation?

Expect recurring effort after the initial build, not only a one-time project. Recurring work includes running vulnerability scans, reviewing firewall rules and access rights on the required cycles, reviewing change and patch records, rotating keys and certificates, and maintaining the policies when systems change. Tooling costs vary by whether you use open-source components alone or commercial products alongside them. Ask any quote to separate one-time build work from ongoing support, to state who performs each recurring task, and to say what happens when your environment changes. Retainers for ongoing support, upgrades and continuous testing are available from DeployOpen, and a quote follows from the written scope.

How DeployOpen prepares Article 9 evidence

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside your own infrastructure, and prepares the protective controls and evidence that Article 9 Protection and prevention calls for. We do not issue audit reports or certifications; your competent authority or independent assessor reviews the outcome, and your organization owns its controls.

How we scope

Agree a written, fixed scope listing which ICT systems supporting critical or important functions fall under the Article 9 controls.
Map the protective policies to your existing documents, including the information security policy and network, access and change policies.
Confirm which evidence owners, tools and review cycles your organization will run after handover, before any build work starts.

How we build

Configure network segmentation and rule logging on your firewalls, with rule reviews scheduled to match your own review cycle.
Deploy strong authentication, including second factors and key protection, on your identity platform within your environment.
Set up change records, patch workflows and automated vulnerability scanning so each change and update leaves a traceable record.

How we hand over

Deliver configuration baselines, runbooks and the documented policies agreed in scope, ready for your management body to review.
Provide a written evidence index that names each control, the system it covers, where its logs or reports live and who reviews them.
Run a walkthrough with your security, operations and compliance staff so they can produce the evidence without us.

How we support

Offer ongoing support, upgrades and continuous security testing as a retainer after the initial fixed-scope engagement.
Keep configurations, documentation and evidence current as platforms are upgraded and as your ICT estate changes.
Confirm with your competent authority or assessor which evidence formats and review intervals they expect before final handover.