Transparency Report

Last updated: 2026-08-13 · Next review: 2026-11-13

This report sets out how we respond to requests for customer data from governments, courts and law enforcement, what customer information actually exists for such a request to reach, what is published about our customers by requirement rather than by choice, and how we act on reports of abuse.

We are an address space lessor and a sponsoring LIR, not a privacy service. Much of what we do is a matter of public record by design, and where we hold customer data we hold it for years because registry policy and tax law require it. This report describes that position plainly rather than implying a level of anonymity our business model does not provide.

1. About This Report

This report covers the Services described in our Terms of Service: IPv4 and IPv6 address leasing, RIPE NCC sponsorship of ASN and Provider Independent resources, and related network services. It complements, and does not replace, our Privacy Policy.

Reporting period

Figures in this report are maintained from 13 August 2026, the date of first publication. We began keeping a formal register of legal and government requests on that date.

We review this report quarterly. If the date above is more than three months old, treat the report as stale and ask us why.

2. Who We Are

DGTL.TECH operates through two legal entities. Which one contracts with you is stated on your invoice and in your service agreement.

The distinction matters for legal process. A demand valid against one entity is not automatically binding on the other, and we do not treat it as though it were. Requests directed at the UK entity are assessed under UK law; requests directed at the US entity are assessed under US law. Where data is held by an entity outside the requesting authority’s jurisdiction, we will say so and, where applicable, point to the mutual legal assistance route.

3. What Is Public by Design

Regional Internet Registry policy requires that address space be registered in a publicly searchable database. This is not something we opt into on your behalf; it is a condition of holding and assigning the resources at all.

Depending on the service and the size of the assignment, the RIPE Database may show:

• the organisation name of the holder or assignee
• the network name (netname) and country
• administrative, technical and abuse contacts
• the maintainer objects authorised to change the record
• a geofeed reference, where one is published

Two cases differ, and the difference is worth understanding before you order:

• Leased address space. The resources remain ours or our upstream’s (Terms §7.1). Registry records identify us as the holder, and may identify you as the assignee.
• Sponsored resources. You are and remain the resource holder (Terms §7.7); we act as sponsoring LIR. Your organisation appears in the registry as the holder of the resources.

We publish what registry policy requires and no more. Personal contact details of natural persons are handled under the RIPE Database terms and our Privacy Policy.

Registry verification is not law enforcement

As a condition of membership and sponsorship, the RIPE NCC may require us to verify and periodically re-verify the identity of resource holders, and may audit our records (Terms §7.3, §7.7). These requests are routine registry administration, not demands for customer data by a public authority, and they are not counted in the table below. We identify them separately so that the numbers in section 4 mean what they say.

4. Government and Legal Requests

The table records binding demands for customer data served on either entity by a court, a government body or a law enforcement agency, together with formal notices under copyright and sanctions regimes.

Reporting period: 13 August 2026 to date.

Where a category is subject to a statutory reporting restriction, we report it at the coarsest permitted granularity rather than omitting the row. A row that disappears from this table should be read as significant.

5. How We Handle a Request

Every request follows the same sequence, whoever it comes from.

1. Verify it. We confirm that the request is authentic, that it comes from a body with authority over the entity served, and that it is served in the legal form that authority requires. Requests made informally — by telephone, by email without process, or by a third party claiming to act for an authority — are not actioned.
2. Check jurisdiction. We establish which entity holds the data sought and whether the requesting authority has jurisdiction over it. Where it does not, we say so and identify the correct route.
3. Narrow the scope. We disclose only the specific data described in the request. We do not volunteer adjacent records, and we push back on demands drafted so broadly that they would sweep in unrelated customers.
4. Notify the customer. Where we are lawfully permitted to do so, we notify the affected customer before disclosing anything, so that they have the opportunity to challenge the request themselves. Where a non-disclosure obligation prevents this, we notify the customer as soon as that obligation lapses.
5. Record it. Every request, and its outcome, is entered in the register that produces the table above.

We reject requests that are defective in form, that exceed the requesting authority’s powers, or that are served on an entity which does not hold the data.

6. What Data We Actually Hold

A request can only reach data that exists. The table below summarises what we hold and for how long; the authoritative and complete version is Privacy Policy §8.2.

Because assignment records exist and are retained, we are able to answer the question “who held this address on this date” when a valid legal request requires it. We would rather state that clearly than let a customer assume otherwise.

7. Warrant Canary

A warrant canary reports the absence of legal processes we would be forbidden from disclosing directly. It only works if you know when to expect the next one: this statement is due to be renewed by 13 November 2026. If it has not been renewed by that date, or if it has been removed or materially reworded, you should assume that one of the statements above can no longer be made.

8. Abuse Reports

Send abuse reports to . This is the contact registered in the RIPE Database for AS61087 and for the address space we manage, so a report sent there reaches the right place whether you found it here or in a WHOIS lookup.

Security vulnerabilities in our own systems go to , as published in our security.txt.

What happens to a report:

1. We acknowledge it and identify the customer. Address space we lease is in active use by an identified customer, so a report can always be routed to someone accountable for it.
2. We pass it to them. Under Terms §7.5 the customer must maintain a valid abuse contact and provide an initial response within 24 business hours.
3. We act if they do not. Failure to address a well-founded report may result in suspension of the affected resources or of the service.

Acting on abuse is a contractual matter between us and our customer. We do not require a court order to suspend resources being used in breach of our Acceptable Use Policy, and a valid abuse report is not a legal request for customer data — the two are recorded and handled separately.

9. Routing Security

Our routing can be verified by anyone, without asking us. We think that is the strongest form of transparency available to a network operator, and we would rather be checked than believed.

• We announce from AS61087. Our peering and facility records are published at PeeringDB.
• We publish Route Origin Authorizations (ROAs) for address space we hold, and we ask lessees to maintain ROAs for space they announce themselves (Terms §7.4).
• We may apply RPKI-based route origin validation on our network.

Announcements, origins and RPKI validity for any of our prefixes can be checked independently through RIPE Stat, the RIPE Routing Information Service, or any public RPKI validator.

10. Geolocation Records

Commercial geolocation databases are third-party products. We do not operate them and we cannot change their contents directly; what we control is the registry data and the geofeed they draw from.

• We register the country of address space in the RIPE Database.
• On request, we can publish a geofeed entry for address space we manage, which the major providers consume.
• We submit correction requests to individual providers where records remain wrong.

Practical guidance on how geolocation data propagates, and how to get a record corrected, is in our FAQ.

11. Changes to This Report

Substantive changes are recorded here rather than made silently. Where a change is made because we can no longer make a statement we previously made, the removal itself is the disclosure.

12. Contact

Service of legal process by email is accepted at the legal address above for the purpose of assessment only; it does not waive any requirement that process be served in the manner the applicable law prescribes.