What else is dns and domain services called?

managed DNS, domain registrar, certificates.

How critical is a dns and domain services vendor by default?

Critical when the paste gives no rating: A DNS failure takes every public service and most internal integrations offline at once, whoever hosts them.

Which obligations attach to a dns and domain services vendor?

DORA: DORA Art. 28, DORA Art. 30, DORA Art. 29, DORA Art. 31; NIS2: NIS2 Art. 21(2)(d), NIS2 Art. 21(3), NIS2 Art. 24; SP 800-161: SP 800-161 SR-6, SP 800-161 SR-8, SP 800-161 SA-4, SP 800-161 SR-13, SP 800-161 SA-9, SP 800-161 AC-20, SP 800-161 CA-3, SP 800-161 IR-6, SP 800-161 CP-2, SP 800-161 CP-4; ISO 27001: ISO 27001 5.19, ISO 27001 5.20, ISO 27001 5.22, ISO 27001 5.23, ISO 27001 5.21.

Which contract clauses does the register look for on a dns and domain services contract?

Registrar lock and transfer rights, zone export, availability, incident assistance, beside the clauses each ticked regime expects on every vendor agreement.

Every vendor category · Cloud and hosting

DNS and domain services

Authoritative name resolution, domain registration and certificates: the addresses every other service is reached by.

How the register reads it

Also called	managed DNS, domain registrar, certificates
Family	Cloud and hosting
Default criticality	Critical when the paste gives none. A DNS failure takes every public service and most internal integrations offline at once, whoever hosts them.
DORA scope	An ICT service: recorded in the register of information and reached by Articles 28 to 31.
Cloud service	Treated as a cloud service: the exit provision is expected (ISO 27001 control 5.23) and its absence is a finding.
Contract focus	Registrar lock and transfer rights, zone export, availability, incident assistance.

What each regime attaches

22 clauses across 4 regimes

Shown on a register for the regimes you tick; with none ticked, the ISO 27001 rows are the default. Requirement text drawn from a human-verified compliance corpus under licence: the corpus statement of each clause, not the instrument verbatim.

DORA, the Digital Operational Resilience Act

Attaches to contractual arrangements for ICT services: cloud, software, network, managed services and data feeds. A supply of hardware, a bank or a courier is recorded in the register only where a service element sits in the contract.

DORA Art. 28 ICT third-party risk: general principles

Financial entities shall manage ICT third-party risk as an integral component of ICT risk, maintain a Register of Information on all contractual arrangements for the use of ICT services, report it to competent authorities, assess risk before entering arrangements (including concentration and subcontracting), and adopt an ICT third-party risk strategy.

Evidence an auditor accepts: A Register of Information of ICT third-party arrangements reported to the competent authority; Pre-contract risk assessment records
Common gap: No Register of Information
Source framework: DORA (Regulation (EU) 2022/2554)

DORA Art. 30 Key contractual provisions

Contractual arrangements for the use of ICT services shall include the mandatory key contractual provisions (e.g. clear service descriptions, locations of data processing, data protection, accessibility/availability/integrity/security, assistance on incidents, audit and access rights, termination rights and exit strategies), with enhanced provisions for serv...

Evidence an auditor accepts: ICT contracts containing the mandatory key provisions (audit/access, termination, exit, security); Enhanced provisions for critical/important-function services
Common gap: Contracts missing audit/access, termination or exit provisions
Source framework: DORA (Regulation (EU) 2022/2554)

DORA Art. 29 Preliminary assessment of ICT concentration risk at entity level

When assessing ICT third-party arrangements supporting critical or important functions, financial entities shall assess ICT concentration risk, including the risks of contracting providers that are not easily substitutable or of multiple arrangements with the same or closely connected providers, and the implications of subcontracting.

Evidence an auditor accepts: ICT concentration-risk assessment for critical/important-function arrangements
Common gap: Concentration risk not assessed
Source framework: DORA (Regulation (EU) 2022/2554)

DORA Art. 31 Designation of critical ICT third-party service providers

The European Supervisory Authorities designate critical ICT third-party service providers, which become subject to the Union Oversight Framework led by a Lead Overseer; financial entities shall account for the use of such providers in their third-party risk management.

Evidence an auditor accepts: Identification of any critical ICT third-party providers used and their oversight status
Common gap: No awareness of critical-TPP designations affecting the entity
Source framework: DORA (Regulation (EU) 2022/2554)

The NIS2 Directive

Attaches to every direct supplier and service provider of the entity, whatever it supplies; the depth of the assessment follows the access and the criticality.

NIS2 Art. 21(2)(d) Supply chain security, covering the relationship with each direct supplier and service provider

The Directive scopes this deliberately at direct suppliers and service providers, which makes the first artefact an inventory of who those parties are and which of them touch the network and information systems behind the service. From there the entity has to manage the security-related aspects of each relationship: what the supplier may access, what securit...

Evidence an auditor accepts: Inventory of direct suppliers and service providers, flagged for access to in-scope systems; Risk assessment per supplier proportionate to the access and criticality involved; Contractual security clauses, including incident notification obligations and audit or assurance rights
Common gap: Inventory built from the procurement system, so shadow and free-tier services are missing
Source framework: NIS2 Directive

NIS2 Art. 21(3) Take account of supplier-specific vulnerabilities and of Union coordinated supply chain risk assessments

Deciding what supply chain measures are appropriate is not left to general judgement. The entity has to take into account the vulnerabilities specific to each direct supplier and service provider, and the overall quality of those parties' products and cybersecurity practices including their secure development procedures. Separately, it must take into account...

Evidence an auditor accepts: Per-supplier assessment records that address that supplier's own vulnerabilities and secure development practice; A watch process for Union coordinated supply chain risk assessments and the outputs it has captured; Decision records showing how each relevant coordinated assessment was reflected in supplier measures
Common gap: Supplier assessment reduced to a questionnaire score with no view of that supplier's actual weaknesses
Source framework: NIS2 Directive

NIS2 Art. 24 Use certified ICT products, services and processes where the Member State requires it

A Member State may require essential and important entities to use particular ICT products, ICT services and ICT processes that are certified under a European cybersecurity certification scheme adopted under Article 49 of Regulation (EU) 2019/881, as a way of demonstrating compliance with particular Article 21 requirements. That requirement can arrive either...

Evidence an auditor accepts: A determination of whether any certification requirement applies, per Member State of jurisdiction; Certificates held for ICT products, services or processes where certification is required; The watch process for delegated acts and national requirements, with dated review
Common gap: Assuming no requirement applies without checking each national transposition
Source framework: NIS2 Directive

NIST SP 800-161 Rev 1

Attaches to every supplier, developer, integrator and service provider of a federal system, with the hardest controls on components and on privileged access.

SP 800-161 SR-6 Supplier Assessments and Reviews

Assesses and reviews suppliers, at a depth matched to what they supply and the access they hold.

Evidence an auditor accepts: assessment methodology and tiering by criticality; assessment records per supplier; review cycle evidence
Common gap: all suppliers assessed with the same questionnaire
Source framework: NIST SP 800-161 Rev 1

SP 800-161 SR-8 Notification Agreements

Establishes agreements requiring suppliers to notify the organization of compromise, vulnerability and relevant change.

Evidence an auditor accepts: notification clauses with defined triggers and timeframes; evidence of notifications received; escalation route when notification fails
Common gap: notification obligation absent or without a timeframe
Source framework: NIST SP 800-161 Rev 1

SP 800-161 SA-4 Acquisition Process

Puts security and supply chain requirements into the contract, including the evidence the supplier must provide.

Evidence an auditor accepts: contract templates carrying security and C-SCRM requirements; evidence of requirements in executed contracts; acceptance criteria tied to those requirements
Common gap: requirements in the template but absent from signed contracts
Source framework: NIST SP 800-161 Rev 1

SP 800-161 SR-13 Supplier Inventory

A control new in this publication: maintains an inventory of suppliers so that exposure to any one of them can actually be answered.

Evidence an auditor accepts: supplier inventory with the systems and components each supports; criticality attached to each supplier; update procedure on supplier change
Common gap: supplier list held by procurement with no link to systems
Source framework: NIST SP 800-161 Rev 1

SP 800-161 SA-9 External System Services

Governs external service providers across their life cycle, including the security roles each party holds.

Evidence an auditor accepts: inventory of external services; agreements defining security roles and responsibilities; monitoring and assessment evidence
Common gap: responsibilities assumed rather than defined
Source framework: NIST SP 800-161 Rev 1

SP 800-161 AC-20 Use of External Systems

Sets the terms under which organizational information may be processed on supplier and provider systems, and verifies them.

Evidence an auditor accepts: inventory of external systems used by suppliers for organizational data; agreements setting the security terms; verification evidence such as assessment or attestation
Common gap: supplier subcontracts processing with no notification
Source framework: NIST SP 800-161 Rev 1

SP 800-161 CA-3 Information Exchange

Governs the connections and exchanges between the organization and its suppliers, integrators and providers.

Evidence an auditor accepts: inventory of supply chain exchanges and connections; agreements documenting each; technical protections and review records
Common gap: connections established for a project and never decommissioned
Source framework: NIST SP 800-161 Rev 1

SP 800-161 IR-6 Incident Reporting

Reports supply chain incidents to the parties who need to know, including other users of the same supplier or component.

Evidence an auditor accepts: reporting thresholds and recipients including external bodies; records of reports made; evidence of onward notification where required
Common gap: reporting obligations to sector bodies unidentified
Source framework: NIST SP 800-161 Rev 1

SP 800-161 CP-2 Contingency Plan

Plans for continued operation when a critical supplier, integrator or component source becomes unavailable.

Evidence an auditor accepts: contingency plan with supplier failure scenarios; identification of critical suppliers and single points of failure; alternate sourcing arrangements
Common gap: plan lists systems but not the suppliers that keep them running
Source framework: NIST SP 800-161 Rev 1

SP 800-161 CP-4 Contingency Plan Testing

Tests the supply chain elements of the contingency plan, including whether alternate sources can actually deliver.

Evidence an auditor accepts: test plan including supplier failure scenarios; test results and lessons; evidence alternate sources were contacted or validated
Common gap: alternate supplier named but never approached
Source framework: NIST SP 800-161 Rev 1

ISO/IEC 27001:2022

Attaches to every supplier relationship through controls 5.19 to 5.23, and to outsourced development through 8.30. With no regime ticked, these rows render as the default.

ISO 27001 5.19 Information security in supplier relationships

Define and apply processes to manage the security risk suppliers introduce.

Evidence an auditor accepts: supplier_risk_assessment; contractual_security_requirements; supplier_security_monitoring
Common gap: Treating all suppliers as low risk
Source framework: ISO/IEC 27001:2022

ISO 27001 5.20 Addressing information security within supplier agreements

Establish and agree the relevant security requirements in each supplier contract.

Evidence an auditor accepts: contract_security_clauses; supplier_risk_assessment; security_incident_reporting
Common gap: missing explicit security clauses
Source framework: ISO/IEC 27001:2022

ISO 27001 5.22 Monitoring, review and change management of supplier services

Regularly monitor, review and manage change in supplier security practice and service delivery.

Evidence an auditor accepts: supplier_security_monitoring_reports; supplier_service_review_meetings; supplier_change_management_records
Common gap: relying on informal verbal updates
Source framework: ISO/IEC 27001:2022

ISO 27001 5.23 Information security for use of cloud services

Govern acquisition, use, management and exit of cloud services against your security requirements.

Evidence an auditor accepts: cloud_service_selection; cloud_contract_management; cloud_security_monitoring
Common gap: Relying solely on provider's security assurances
Source framework: ISO/IEC 27001:2022

ISO 27001 5.21 Managing information security in the ICT supply chain

Extend security requirements down the ICT products and services supply chain.

Evidence an auditor accepts: supplier_security_requirements; contractual_security_clauses; supply_chain_risk_assessments
Common gap: Treating supplier security as one-off check
Source framework: ISO/IEC 27001:2022

Findings this category can raise

Single-source vendors with no fallback named
The paste marks these vendors as the only source and names no fallback. Every regime treats that as the concentration it exists to surface: the question is what happens on the day the vendor is unavailable, and who has written the answer down.
Concentration at or above the threshold
One vendor carrying a quarter or more of the spend, the top three carrying sixty percent or more, or one country carrying half or more: the register names the share so the dependence is a recorded one. Concentration is often the right commercial choice; the regimes ask that it be assessed, not avoided.
Contracts ending inside 90 days with no re-tender noted
A contract end inside ninety days of the as-at date, with no re-tender, renewal or extension recorded in the paste. Ninety days is shorter than most exit plans and most procurement cycles; the finding lists the days left beside each vendor.
Critical vendors with no contract end recorded
A vendor rated critical, by the paste or by derivation, with no contract end date. A register with no end date cannot schedule the exit, the renewal or the re-assessment; the date belongs in the register even when the contract rolls.
DORA register-of-information fields missing
DORA asks financial entities to keep a register of information on every contractual arrangement for ICT services, in the columns the supervisory authorities' template sets: identification, type of service, the function it supports, criticality, country of provision, substitutability, sub-outsourcing and the exit plan. These vendors are ICT services in that sense and one or more of those columns is blank.
NIS2 supplier assessment not evidenced
The Directive asks an essential or important entity to manage the security of each direct supplier relationship and to take account of each supplier's own vulnerabilities and practices. These vendors touch in-scope systems and the paste carries no assessment date for them: the assessment may exist, but the register cannot show it.
Cloud services with no exit plan
A cloud service (infrastructure, platform, or an application delivered as a service) whose exit plan column reads no or is blank. Exit is the clause every regime names for cloud, because the data and the runtime are the provider's until the contract says otherwise.
Sub-outsourcing chains longer than one hop
The paste names a chain of two or more parties beneath a vendor. Each hop is a relationship the buyer has no contract with; DORA asks for the chain in the register, NIS2 asks that the supplier's own suppliers be considered, and the notification duty has to run the whole length of it.

Do this for every vendor on your list

Paste the list and get this classification for every vendor at once, with the share of spend and systems, the country it lands in, the criticality, the findings and the obligation rows per regime. Eight vendors free, no account.

Build my vendor register

Content delivery network · Infrastructure as a service