Summary

  • After a disputed change or outage, the current registration record answers only what the service presents now. Public entity history can show prior values. A defensible account also needs the request, authenticated principal, human or automated authority, approval, before-and-after state, execution event, restoration history and public effect.
  • WHOIS and RDAP were built to make registration information usable, not to serve as complete forensic systems. RDAP's event model requires an action and date but makes the actor optional. RIPE Database history and ARIN WhoWas add valuable historical views while retaining privacy and scope limits.
  • “Immutable” should mean that alteration, deletion, reordering and equivocation become detectable. It requires append-only event design, separated administration, off-system copies, trustworthy time, key protection, gap checks and periodic commitments witnessed outside the registry's ordinary control plane.
  • Cryptography proves bounded facts. A signed timestamp can show that data existed before a time; a hash chain can reveal later alteration; an inclusion proof can show that a committed event entered a log. None proves that the underlying claim was true, that a credential represented the named person or that the decision complied with policy.
  • Controlled external proof is preferable to publishing raw security logs. Public commitments and aggregate reports can establish continuity; independent auditors, escrow custodians or courts can inspect protected detail under defined rules; affected holders should receive incident-specific evidence without exposing unrelated personal or security data.
  • Evidence rights need deadlines and remedies. Resource holders should be able to trigger preservation, obtain a signed event chronology, challenge attribution, request independent review and receive correction or restoration when the record is wrong. Repeated evidence gaps should produce governance consequences rather than a statement that no conclusion can be reached.
  • Number Resource Society can propose a common event vocabulary, evidence-request clause, external-commitment profile and comparative retention register. Its role should be member support and standards advocacy, not custody of every log or a claim to determine legal admissibility.

One record, three plausible histories

An address block disappears from an organisation's account during a registry service interruption. When service returns, RDAP shows the block registered to another entity and a “last changed” date within the outage. The first holder says it never authorized a transfer. The new holder presents correspondence that appears to confirm one. Registry staff say a restoration task reapplied a transaction that had been approved before the interruption.

All three accounts could fit the same current record. A credential may have been compromised and used to submit a request. A staff member may have approved a legitimate transfer whose execution was delayed. An automated recovery task may have replayed a previously rejected or superseded transaction. A batch correction may have written the wrong holder identifier. A later manual edit may have repaired one field while leaving the public timestamp as the only visible clue.

The decisive questions are not contained in the current entity. Who initiated the request? Which authenticated principal was used? Which natural person or service stood behind it? What authority did that principal possess at the time? Who approved the change, under which policy and evidence? Which application version committed it? Did the database acknowledge the transaction before the outage? Which backup and event stream were used in recovery? When did public services expose each state?

Without those answers, “the database says” is circular. The disputed system is being asked to prove itself by displaying its present output. Registry legitimacy requires a record that can distinguish the three histories even when the incident is embarrassing, the staff has changed and litigation begins years later.

Current registration is not an audit trail

WHOIS and RDAP answer practical questions about Internet number resources: which registry serves a range, which organisation and contacts are associated with it, which status applies, and when selected events occurred. Operators, researchers, abuse teams and legal advisers need that current view. Its public function should not be disparaged merely because it cannot answer every forensic question.

But a current entity is the result of prior acts, not a record of all of them. A last-modified field identifies a time assigned by a server. It does not necessarily identify the requester, approver, credential, application path or reason. An RDAP event can include an actor, but RFC 9083 explicitly permits events where actor identity is not captured. Even where an actor string exists, it may name an account, registry handle or service rather than the person who made the decision.

The public view also reflects deliberate minimization. Contact details may be redacted. Sensitive authentication information must not be exposed. Old personal data may be filtered. A registry can therefore operate a sound internal audit system while publishing a narrower history, or publish extensive entity versions while retaining weak internal attribution.

Accountability fails when these layers are conflated. A holder should not be told that public RDAP is complete proof merely because it is authoritative for current registration. Nor should outsiders assume that a filtered public response means no internal evidence exists. The correct question is which evidentiary proposition each record can support.

Twenty-five years of history improved visibility, not certainty

The evolution of the RIPE Database shows why historical visibility matters. RIPE-767 says historical data was added in 2001 and made publicly available in 2013. Previous versions are saved when supported entities are updated, while history queries and privacy rules determine what users can retrieve. RIPEstat Historical Whois exposes versions for supported RIPE Database entities and permits selection by version or time.

This is a substantial accountability gain. A researcher can compare an entity across time instead of relying on a screenshot. A resource holder can identify when a route or organisation attribute changed. An incident investigator can reconstruct public states and discover that an apparently stable current record had a contested predecessor.

The history still has boundaries. RIPE-767 discusses excluded entity types, filtering of personal data and treatment of deleted and recreated entities. A version sequence records stored entity states, not every failed request or internal approval. It may reveal that a field changed at 14:03 without proving who controlled the credential or why staff accepted the evidence.

ARIN's WhoWas service offers another model: approved access to public historical registration information for an IP address or ASN, including related organisation and contact histories. Its controlled access recognizes both research value and data sensitivity. Again, “public history” is the defining scope. It is not advertised as a full security-event archive.

The lesson from 2000 onward is not that registries ignored history. It is that successive public-history improvements solve only part of the evidentiary problem.

Four records should be kept conceptually separate

A strong registry evidence design distinguishes at least four records. The first is current authoritative state: the registration and related information the registry now serves. It must be accurate, available and clearly time-bounded.

The second is public state history. It records earlier public versions, creation, modification, deletion or transfer events subject to privacy and policy. This layer supports research, operational context and basic dispute reconstruction. Its public fields should have stable semantics and documented omissions.

The third is the protected operational audit trail. It records requests, authentication, authorization, approvals, automated decisions, application events, administrative access, database commits, replication, restoration and disclosure. Much of it cannot be public because it includes security and personal information. It should nevertheless be complete enough for independent review.

The fourth is external proof. A registry periodically commits to hashes or signed roots representing its protected event sequence and places those commitments with independent witnesses. Later, it can prove that a disclosed event was included and that the log evolved consistently without revealing every unrelated event. Auditors or escrow custodians can hold fuller protected copies under defined access.

These layers reinforce each other. Current state tells operators what to use. Public history shows visible change. Protected events explain control and causation. External proof limits the registry's ability to rewrite that explanation after a dispute. No layer should impersonate another. Publishing raw audit events would create harm; keeping every integrity claim internal would leave the system self-authenticating.

Evidence must be designed around propositions

The phrase “the logs show” is incomplete. Logs show particular observations created by particular systems. An investigation should state the proposition to be proved and identify the records that support it.

To prove that a request was received, preserve the request bytes, channel, receive time, authenticated service principal and a registry receipt. To prove that an identified person authorized it, preserve the identity binding, authentication event, organizational role, approval step and any out-of-band confirmation. To prove that policy permitted the act, preserve the applicable policy and procedure version, decision inputs, reviewer and reason.

To prove execution, preserve the transaction identifier, application release, service identity, before-and-after values, database commit and replication result. To prove public effect, preserve responses from WHOIS, RDAP or related services from independent observation points. To prove recovery, preserve backup identifiers, replay ranges, integrity checks and reconciliation with the event sequence.

The evidence may support one proposition and not another. A valid multifactor login proves that enrolled factors were used; it does not prove the account holder personally acted. A database commit proves that a transaction wrote data; it does not prove the transfer agreement was genuine. A public history entry proves a visible version existed; it may not prove how long every cache served it.

This proposition map prevents overstatement. It also reveals missing controls before an incident. If no record can connect an approval to the exact data committed, the registry knows which evidentiary joint needs reinforcement.

Identity is a chain, not a username

Attribution begins with a technical principal but cannot end there. Registry changes may originate from a member portal user, an API credential, an email update authenticated by a maintainer, a staff console, a support case, a scheduled task or an emergency administrator. The same organisation can use several paths.

The audit event should identify the immediate principal in a stable, non-reassigned form. It should record the authentication method, credential identifier, session or request identifier and relevant assurance result without storing reusable secrets. If a service account acted, the event should identify the service and the upstream human approval or rule that authorized it. If staff acted on behalf of a holder, both the staff principal and customer authority should be linked.

Shared accounts destroy useful attribution and should be eliminated for high-value actions. Delegated roles should have start and end times. When an employee leaves or a maintainer changes, old events must continue to resolve to the historical person or service rather than the account's new owner. Identity records need their own protected history.

Compromise remains possible. A log can prove that credential X was used from device Y; it cannot prove the legitimate person held the device. Risk signals, out-of-band confirmation and later challenge may alter confidence. The incident account should separate technical attribution from human attribution and state uncertainty.

The purpose is not to attach a person's public name to every edit. It is to ensure that a protected reviewer can trace authority through the chain. Privacy can restrict disclosure without making the chain disappear.

Authorization must be captured at the moment it matters

A properly authenticated request can still be unauthorized. The user may lack authority over the resource, hold an expired corporate role, exceed a delegated scope or seek an action blocked by transfer, sanctions or dispute status. Evidence therefore needs the authorization decision as it existed when the registry acted.

The event should record the resource set, requested action, applicable role, policy constraints, holds, approval threshold and decision result. It should identify which authoritative data was consulted and its version. If two officers were required, both approvals and their order matter. If staff overrode a control, the exception authority and reason should be explicit.

This snapshot protects all parties. A later role change should not make a once-valid approval look invalid. A later correction should not make an invalid act appear retrospectively authorized. Investigators can assess the decision against the rules and facts available at the time rather than the database's current state.

Complex cases need evidence references, not sensitive documents copied into every log event. A transfer agreement, court order or corporate record can be stored in a protected evidence system with a digest and stable identifier. The event links to it, and authorized reviewers can verify integrity. Access and retention can differ from the operational log while the relationship remains provable.

Authorization evidence also disciplines automation. A task should not merely record that its service account had write permission. It should record the rule and input state that made this particular write permissible. Otherwise broad machine access becomes a substitute for policy.

“When” has more than one clock

Disputes frequently turn on time: whether a request preceded a deadline, whether approval occurred before a court order, whether a transfer completed before an outage, or whether a public record changed before a route announcement. One timestamp cannot answer every question.

An event should distinguish client creation time, registry receipt time, authentication time, approval time, database commit time, replication time and first public observation. These times may differ legitimately. The client clock may be wrong. A request can wait for review. A transaction can commit before a read replica updates. A public service can cache state.

Registry systems should use synchronized trusted time and record clock health. Sequence numbers or append positions provide ordering even when wall-clock time is uncertain. Events should identify the time source and precision appropriate to the act. Manual evidence received from another jurisdiction may have only a date; an API commit may have subsecond precision. False precision is not strength.

RFC 3161 provides a way for a trusted timestamp authority to create evidence that a datum existed before a particular time. That can strengthen periodic event commitments or critical transaction receipts. It does not identify the requester by itself, and it does not prove that the timestamped statement was true.

After an incident, the chronology should preserve clock uncertainty and corrections. Quietly normalizing all events to a clean timeline can erase the very discrepancy investigators need to understand. Time evidence is credible when it states both order and limitation.

Before-and-after values need transaction boundaries

A registry entity can contain many fields, references and derived states. Recording only “entity updated” forces investigators to reconstruct the difference from backups, if those backups still exist. Recording only the final value loses what was replaced. High-value changes need a canonical before-and-after representation.

The transaction event should identify the exact fields added, removed or changed and the stable identifiers of related entities. It should preserve hashes of canonical representations so later exports or displays can be verified. The record should say whether the change was one atomic transaction or a sequence of writes. A transfer that updates holder, contacts, account access and routing-security eligibility should not appear as an unexplained row of unrelated edits.

Derived data needs lineage. If a public RDAP response is generated from several internal tables, the registry should be able to identify which committed state produced it. If a database trigger recalculates status, the triggering transaction and trigger version matter. If a queue updates a secondary service later, its event should point back to the initiating transaction.

Rollbacks should never erase the original act. The log should record the erroneous change, detection, reversal authority and restoring transaction. The current entity may match its starting value, but an incident still occurred. Treating rollback as deletion creates a false appearance that nothing happened.

Transaction boundaries make remedies possible. A registry can reverse the affected change without guessing which later legitimate edits must remain. It can also tell a court or auditor exactly what state was altered and by which committed act.

Automation needs a human-readable reason chain

Modern registry services use automation for validation, synchronization, renewal, bulk correction, sanctions screening, data cleanup, replication and recovery. Recording “system” as the actor is nearly useless. It names the category of executor while concealing the decision.

An automated event should identify the service, release or rule version, job identifier, trigger, input references, decision result and code path at a useful level. If a scheduled task replays queued transactions after an outage, each resulting write should link to both the original request and the recovery run. If a model or risk score flags an account, the record should preserve the score version and facts used without exposing unrelated proprietary details.

Human approval should be linked where required. A staff member may authorize a batch while the service executes individual writes. Both are actors in different senses. The log should not attribute every row solely to the staff member or solely to the machine.

Software provenance matters because a defect can produce valid-looking but unintended records. Investigators need to know which release transformed the inputs. Deployment time, configuration version and feature flags can explain why two otherwise identical requests produced different results.

The public incident report need not publish code internals. It should be able to state, with support, that a specified automated task applied a stale transaction because a deduplication control failed, and that the task affected a defined set of records. Human-readable causation depends on machine-readable lineage.

Immutability means detectable interference

No digital log is metaphysically immutable. Administrators can delete disks, keys can be stolen, software can be replaced and organizations can fail. The practical goal is to make unauthorized alteration, omission, reordering and inconsistent presentation detectable with high confidence.

An append-only event store is a start. Each record can include the hash of the previous record or belong to a Merkle tree whose signed root commits to the sequence. The registry can write events to a security domain separate from the application that creates resource records. Privileged access to the log should be narrower than access to the registry database and should produce its own events.

Copies should leave the ordinary control plane promptly. An attacker who can change both the database and every audit copy can manufacture agreement. Off-system replication, write-once retention, independent custody and periodic external commitments raise the cost and visibility of rewriting history. Gap monitors should detect missing sequence ranges; restoration should reconcile them rather than silently begin a new log.

Cryptographic keys need lifecycle records. A signed root is weak if administrators can backdate signatures or replace keys without notice. Key generation, rotation, compromise and retirement should be externally documented. Long-term evidence may require renewed timestamps or digest algorithms as cryptographic assumptions age; RFC 4998 offers relevant evidence-preservation concepts.

Immutability is therefore a system of separation and witnesses. A storage setting labeled “retention lock” is not enough if the same unchecked administrator controls the setting, the application and the evidence presented after the incident.

External proof need not expose the event

The registry can commit publicly to the integrity of protected events without publishing their content. At a regular interval, it can construct a tree of event digests, sign the root and send it to independent witnesses. The root reveals little by itself. Later, an authorized reviewer can receive an event and inclusion path proving that the event belonged to the committed set.

RFC 9162, Certificate Transparency version 2, provides a useful analogy. Certificate logs use signed tree heads, inclusion proofs and consistency proofs so monitors can test append-only behavior and detect conflicting histories. A registry audit system would have different privacy, threat and governance requirements, but the institutional insight transfers: a service should not be the sole keeper of the evidence used to prove its own past.

Witnesses can include independent auditors, designated community monitors, escrow providers and perhaps other RIRs under reciprocal arrangements. Diversity matters. Five witnesses operated by one contractor are less independent than two with separate control. Witnesses need stable keys, retention and a way to alert on missed or inconsistent commitments.

The commitment schedule should reflect risk. Daily roots may be adequate for routine events; critical transfer or emergency-administration actions may receive immediate receipts and trusted timestamps. The registry should disclose missed commitment periods and repair them without pretending the gap never existed.

External proof establishes continuity and inclusion, not correctness. A false event can be immutably logged. That is still useful: the registry cannot easily replace the false event with a more convenient account later. Review can focus on whether the decision was authorized and true.

Public transparency and protected evidence can coexist

A demand to publish every registry audit event would expose authentication patterns, personal data, security investigations, internal network details and commercially sensitive transactions. It could help attackers map privileged roles and identify periods of defensive weakness. Accountability should not require reckless disclosure.

The public layer should contain stable current records, appropriately filtered history, service incidents, aggregate control performance, commitment roots and verification information. It can disclose how many critical events were committed, whether sequence or witness gaps occurred, how many evidence requests met deadlines and whether independent assurance found material exceptions. These reports need defined local denominators.

Affected holders should receive more. An incident-specific pack can include their requests, account and role events, approvals, changes, public observations and remediation, with unrelated identities redacted. A holder challenging a transfer needs enough to test authorization, not every event involving another member.

Independent reviewers can receive protected detail under confidentiality and publish bounded findings. Courts or regulators can use lawful disclosure routes. Security researchers can receive de-identified or scoped data where public benefit justifies it. Every disclosure should itself be logged.

This tiered design answers the false choice between secrecy and exposure. The registry proves that evidence existed and was preserved; authorized parties inspect what they need; the public sees whether the system met its commitments. Confidentiality has a rule, a custodian and a review path rather than becoming a reason that no one outside the implicated department can verify anything.

Retention should follow risk and dispute time

Keeping every event forever is expensive and dangerous. Deleting high-value evidence after a short operational period can make member rights meaningless. Retention needs categories tied to purpose, sensitivity, legal obligation and the time within which disputes realistically emerge.

Critical registration events include allocation, assignment, transfer, return, revocation, holder identity change, contractual status, account recovery, authoritative contact change, reverse delegation, RPKI eligibility and emergency intervention. Their core evidence may need to survive for the life of the resource relationship and a defined period afterward. Routine query telemetry and low-risk diagnostics can expire much sooner.

The retention schedule should state what is kept, in which form, where, under whose control and with what deletion proof. Hashing personal data is not automatic anonymization; predictable values may remain linkable. Minimize fields before commitment and separate identity mapping from event integrity where possible.

A preservation trigger must suspend relevant deletion when an incident, complaint, appeal, audit or legal claim is known. The trigger should cover related systems and backups, not only the main log table. Staff should record the scope, authority, start and eventual release of the hold.

Long-term evidence also needs readability. An encrypted archive is useless if keys, formats or software are lost. Periodic verification, format migration and renewed cryptographic evidence should be documented. Retention is not the act of keeping bytes; it is maintaining the ability to interpret and authenticate them when institutional memory has moved on.

Privacy risk grows with evidentiary ambition

A comprehensive event trail can become a map of people, organizations, disputes and network operations. It may reveal which employee controlled a resource, when an acquisition was prepared, which customer faced sanctions review, or which addresses were the subject of an abuse investigation. Stronger accountability creates a valuable target.

Data minimization should begin with the proposition map. Record enough to establish identity, authority and action, but avoid copying entire documents or message bodies where a protected reference and digest will do. Separate operational identifiers from public identity. Restrict free-text fields, which often accumulate unnecessary personal information and inconsistent allegations.

Access should be role-based and purpose-bound. Database administrators do not automatically need human identity evidence; investigators do not automatically need production credentials. High-risk searches and bulk extraction should require approval and be logged. Emergency access should expire and receive review.

Affected individuals and organizations need correction rights for inaccurate identity metadata, while the historical event remains preserved. A correction should append a new statement and link it to the disputed one, not rewrite the evidence. Where law requires deletion or restriction, the system may retain a commitment or sealed proof that an event existed while removing accessible personal content under documented authority.

Independent assurance should test privacy as well as integrity. An incorruptible log that leaks member identities is not a success. Registry evidence deserves legitimacy only when it can survive both a hostile administrator and a data-protection complaint.

Recovery is where weak histories become authoritative

An outage does not merely interrupt queries. It can separate accepted requests, committed database state, replicas, queues and public responses. Recovery staff must decide which events to replay and which snapshot to trust. Those choices can alter registration history.

A resilient design establishes a recovery point in the event sequence, verifies the backup against an external commitment and replays later committed transactions in order. It identifies requests that were received but never committed, transactions committed but not replicated, and public changes served before the failure. Each category receives a distinct disposition.

Idempotency is essential. Replaying a transfer twice should not create two consequences. A recovery task should recognize previously committed transaction identifiers. If it encounters an ambiguous operation, it should quarantine it for review rather than choose the most convenient state. Manual decisions made during restoration need the same identity and authorization evidence as ordinary changes.

After service returns, reconciliation should compare current authoritative state, public services, protected events, external commitments and affected customer records. Differences should be reported and resolved through appended corrective transactions. Starting a clean log after restoration destroys the bridge across the event most likely to be disputed.

Continuity exercises should include partial loss, not only total database restoration. A queue may survive while its deduplication table does not. One replica may accept writes during a partition. An audit sink may lag. Testing these uncomfortable states reveals whether the registry can prove which history became authoritative and why.

Privileged action is part of the record, not above it

Registry staff sometimes need to correct data, enforce policy, respond to security incidents or comply with legal orders. These powers are legitimate. They are also the powers most capable of bypassing ordinary member controls.

Every privileged change should identify the staff principal, approved ticket or case, authority, reason category, affected resources, before-and-after values and whether the member was notified. High-impact actions should require two-person approval or post-action independent review where urgency prevents advance approval. Direct database writes should be exceptional and should generate evidence outside the database being changed.

Administrative access to logs must also be recorded. An investigator who exports events, an engineer who changes retention settings and an administrator who rotates signing keys all alter the evidence environment. Their actions should go to a separately protected stream. Otherwise the people capable of editing history are invisible within it.

Secrecy can be justified for a limited period by security, privacy or court order. The event should still record that a restricted authority exists, who reviewed it and when the restriction will be reconsidered. “Legal” or “security” without a bounded reference is not an audit reason.

The objective is not to deter staff from acting. It is to protect legitimate action from later suspicion and expose improper action when it occurs. A well-recorded emergency correction is more defensible than a nominally routine edit that no one can attribute.

Incident investigation needs a shared chronology

Each party brings different evidence. The holder has portal receipts, emails, corporate authority and network observations. The registry has authentication, approval, application, database and recovery records. Public observers have WHOIS, RDAP, routing and archive snapshots. An auditor may hold external commitments. The investigation should correlate them without assuming one source is inherently complete.

The chronology should begin before the first visible symptom. It should include relevant account and role changes, failed attempts, successful requests, holds, staff access, software deployments, commits, replication, public observations, alerts, recovery and corrections. Times should identify source and uncertainty. Contradictions should remain visible until resolved.

Investigators should preserve original records and perform analysis on copies. Exports need hashes, custodian identities and access logs. Queries used to select events should be recorded so a later reviewer can test whether relevant data was excluded. If a log source was unavailable or retention had expired, the report should state the gap and its consequence.

Cause, authority and effect should be separate findings. A compromised credential may explain request origin; weak recovery may explain execution; a stale public cache may explain duration. One root-cause label cannot fairly allocate all responsibility.

The affected holder should have a chance to comment on factual chronology without receiving a veto over findings. Material corrections should append to the report. A shared chronology earns trust by showing how disagreement was handled, not by smoothing every conflict into unanimous prose.

“No evidence of misuse” needs a denominator

After a security event, institutions often state that log review found no evidence of misuse. The sentence may be accurate and reassuring. Its value depends on what the logs could detect.

APNIC's April 2025 Whois data incident report said automated monitoring detected that hashed authentication details had been exposed to four entities with bulk data access, that the error was rectified quickly, that passwords were reset and that APNIC analyzed logs for signs of Whois misuse. It is a useful example of monitoring, containment and review.

The public report does not purport to publish the underlying logs. A reader therefore cannot infer the retention period, event coverage, identity resolution, detection query, false-negative risk or independent verification. That is not proof of a deficient investigation; it is the limit of the public statement.

A stronger formulation would describe the denominator: which update interfaces and event period were reviewed, which misuse patterns were detectable, whether affected credentials could be linked to actions, which gaps existed and who reviewed the conclusion. Sensitive methods can remain protected. The institution can publish enough to distinguish “we found no matching events in complete relevant logs” from “available logs did not permit a conclusion.”

Evidence-aware language protects credibility. Absence of observed misuse is not proof that no misuse occurred. It can still be strong evidence when the covered population and detection limits are explicit.

Auditors should test reconstruction, not policy binders

An audit can confirm that a retention policy exists while never testing whether one disputed change can be reconstructed. Registry assurance should include event-level sampling and end-to-end exercises.

The auditor can select critical transactions across portal, API, staff and automated paths. For each, it should trace request, identity, authority, approval, before-and-after state, commit, replication, public response, external commitment and retention. It should test negative events such as rejected requests and expired roles, not only successful ordinary changes.

The assessment should examine privileged access, log-administrator separation, clock integrity, sequence gaps, backup restoration, key rotation, legal holds and disclosure. It should attempt to produce an incident pack for a historical sample within the promised time. If the pack depends on one employee's memory or an unsupported tool, the control is not durable.

Auditor independence and scope must be clear. A financial audit may not cover security attribution. A penetration test may not cover evidence retention. A certification badge may exclude the member portal or recovery environment. Public assurance should state systems, period, criteria and material exceptions.

Protected details can remain confidential, but the board and members need a useful result: whether critical events were reconstructable, whether external commitments matched, whether gaps were detected and whether remediation closed them. Assurance should test the registry's capacity to explain a bad day, not merely its ability to describe a good process.

Courts need custody and context, not a log dump

When a transfer, revocation or holder identity reaches court, a large event export is not self-explanatory. The court needs to know who created the records, how the system operated, how integrity was protected, which clocks were used, who collected the evidence and whether the disclosed set is complete for the question.

The registry should be able to produce a signed chronology, original event extracts, verification material, system description, custodian declaration and access history. It should distinguish records created in ordinary operation from notes created for litigation. The latter may be useful but do not carry the same contemporaneous character.

Chain of custody begins before litigation. If staff routinely export events without hashes or overwrite identifiers, a careful legal handoff cannot repair the original weakness. External commitments and protected replicas help show that relevant records existed before the dispute intensified. Trusted timestamps can support timing claims, subject to their bounded meaning.

Admissibility and evidentiary weight vary by jurisdiction. A cryptographically sound log is not automatically admissible, and a conventional business record is not automatically weak. Privacy, privilege, discovery and court orders differ. The design target is not one universal legal formula; it is a record whose creation and preservation can be explained honestly wherever review occurs.

The court also needs uncertainty. If identity binding was incomplete or a clock drifted, the registry should state it. Overclaiming turns a technical limitation into a credibility failure. A precise limitation is often more useful than a confident but unsupported attribution. Nothing in the technical design predetermines admissibility or the weight a particular tribunal will assign.

Evidence rights should exist before the dispute

A holder should not need extraordinary litigation merely to learn how its registration changed. Subject to applicable law, service agreements and published procedures should define an evidence-request right for critical events affecting the holder's resources or account.

The right should include immediate preservation, acknowledgement, a preliminary chronology, a final incident pack and a route to independent review. Deadlines can vary by severity, but silence should not be an option. The registry may redact unrelated personal and security data and can require reasonable identity verification. It should identify each withheld category and the basis for withholding.

The holder should be able to challenge technical and human attribution. If the registry says an administrator approved a transfer, the administrator can dispute account use. The review should consider credential compromise, role state and out-of-band evidence rather than treating the login as conclusive. Corrections should append to the record and propagate to public history where appropriate.

Fees should not make ordinary accountability inaccessible. Complex litigation support can be chargeable, but an incident pack after a material service error is part of remediation. Members should know retention limits before they delay a request.

An independent reviewer needs authority to inspect protected records and report bounded findings. The reviewer need not replace the board, community or court. It provides a credible route when the department that made the change is also answering the complaint.

These rights turn logs from an internal security asset into an accountable service. Evidence has institutional value only when affected parties can invoke it under fair rules.

Missing evidence needs a remedy of its own

A registry may be unable to reconstruct an event because a system failed, a retention period expired, a privileged act bypassed logging or an incident destroyed the record. The absence cannot always decide the underlying dispute. It should never be treated as neutral.

The registry should disclose the missing source, expected coverage, reason for absence, detection time and effect on confidence. It should preserve substitute evidence such as public history, customer receipts, backups and witness commitments. Investigators should avoid inventing certainty from whichever source survived.

Remedies can include restoring the last uncontested state, placing a temporary hold, funding independent review, extending appeal time, waiving fees or compensating direct reconstruction costs. The appropriate response depends on risk and jurisdiction. The principle is that the institution controlling evidence should bear a consequence when its failure makes a member's case materially harder.

Repeated gaps are governance information. The board should receive counts by critical event class, not just total log availability. An uninterrupted audit service that omitted every emergency administrator action is not healthy. Independent assurance should track remediation, and material evidence destruction should trigger stronger oversight.

No presumption should enable hijacking. A claimant cannot obtain a resource merely because one event is missing. Interim controls can protect all sides while evidence is assessed. The aim is balanced burden: the holder provides its authority; the registry proves its controlled acts; uncertainty created by a registry control failure is not silently imposed on the holder.

Cross-registry comparison requires common questions

RIPE Database history, ARIN WhoWas and RDAP event fields illustrate different public evidence capabilities. They should not be ranked by counting exposed fields. Legal context, privacy design, entity models, access conditions and historical coverage differ.

A useful comparison asks the same questions at each layer. Which entity types have public history? Are deleted and recreated entities represented? Which fields are filtered? Does the service expose action time, actor or difference? How does a holder request protected history? Which critical operational events are recorded internally? How long are they retained? Are event roots witnessed externally? Can an auditor reconstruct a transfer and a recovery?

The comparison should distinguish published fact from unanswered question. A registry may have strong internal controls it does not describe publicly. Lack of documentation is an accountability issue but not proof of absence. The registry should be invited to provide current evidence and explain lawful restrictions.

Performance reporting needs local denominators: evidence requests received, packs delivered within the target, critical transactions sampled, commitment intervals missed and material gaps found. These figures should not be combined into an invented global maturity score without comparable scope.

The objective is convergence on minimum proof, not identical public databases. Each region can preserve its policy and privacy choices while ensuring that a consequential change is attributable, reconstructable and externally integrity-checked. Common questions make differences governable.

The NRO continuity standard points toward evidence custody

The NRO RIR Governance Document Version 2 text calls for stable, reliable, secure, accurate and accountable registry services. It also describes continuity and protected sharing with an emergency operator sufficient to perform RIR services if necessary.

Those expectations have an evidentiary implication. An emergency operator cannot safely continue authoritative registration from a current data snapshot alone. It needs the unresolved request state, transaction sequence, authority records, holds, account roles, audit history and verification material necessary to distinguish legitimate pending action from replay or corruption.

Escrow should therefore preserve more than database tables. It should include documented event formats, keys or verification paths, retention metadata, software needed to interpret records and a tested handover procedure. Private credentials require careful treatment; the emergency operator needs continuity without receiving unchecked historical access.

The governance text does not prescribe this detailed architecture. It supplies the high-level duty. Regional communities and operators must define what evidence is sufficient. A continuity plan that can restore query availability but cannot prove the legitimacy of restored state leaves the most sensitive risk unresolved.

External custody also limits institutional capture. A board, receiver or emergency operator should not be able to rewrite the predecessor's history without detection. Equally, the predecessor should not be able to withhold every record needed for lawful succession. Evidence continuity is part of service continuity because authoritative power rests on an explainable chain.

Number Resource Society can standardize the questions

Number Resource Society can help resource holders ask for evidence without claiming custody or judicial authority. It can publish a model critical-event record describing request, identity, authorization, decision, change, execution, public effect, commitment and remedy fields. The model should distinguish required protected fields from appropriate public disclosure.

It can also propose a member evidence clause: preservation triggers, response deadlines, redaction rules, independent review and consequences for missing records. Regional legal review would still be required. The clause's value is to give small operators a starting point comparable to what a large carrier might negotiate.

A comparative register can record public-history capabilities, documented retention, external assurance, commitment practice and evidence-request procedures across RIRs. Unknowns should remain unknowns. NRS should not infer weak security from a quiet website or convert one member dispute into a regional rate.

Technical convening can test a privacy-preserving external commitment profile. RIRs, auditors and operators could verify inclusion and consistency using synthetic events, then publish the limits. A test should not place real member activity in an uncontrolled public log.

Finally, NRS can help members preserve their own side of the chain: receipts, authority records, correspondence and public observations. Registry evidence is stronger when it can be compared with independent customer evidence.

The role is useful because it is bounded. NRS's charter and FAQ are first-party advocacy, not proof of neutral audit capability. Standards and member support can improve accountability without pretending to decide ownership or admissibility.

Implementation can begin with the highest-value acts

A registry need not rebuild every system at once. It can begin by identifying critical event classes: resource issuance, transfer, return, revocation, holder identity, contractual status, account recovery, privileged access, reverse delegation and routing-security eligibility. For each, it maps the proposition and evidence chain.

The first technical step is stable identifiers across systems. A customer request, support case, approval, transaction, public version and incident should be linkable without relying on free text. The second is protected before-and-after events with synchronized time and explicit principals. The third is separate storage and daily external commitments.

The registry can then add member receipts and evidence-request procedures. Synthetic end-to-end tests should verify that a critical transaction can be reconstructed and disclosed with appropriate redaction. Recovery exercises should prove that committed events survive restoration and that replay does not duplicate effects.

Public reporting can start modestly: commitment continuity, sampled reconstruction success, evidence-request timeliness and material exceptions. The registry should resist a premature score that rewards volume over relevance. One complete transfer trail is more informative than billions of undifferentiated server messages.

Legacy history will remain imperfect. The institution should document the start date and coverage of stronger controls rather than imply retroactive completeness. Old backups and public history can be preserved without being upgraded into evidence they were never designed to supply.

Incremental implementation is credible when the target state, priorities and gaps are public. “Too complex” is not a permanent answer for records that allocate scarce and operationally important resources.

The cost argument should include the cost of uncertainty

Protected logging, external witnesses, long-term verification and evidence review cost money. Storage is only a fraction. Identity integration, key management, privacy review, auditor time, recovery tests and member support require sustained budgets. A regional registry should not promise litigation-grade treatment for every low-risk event without understanding the burden.

Risk-based design controls cost. Critical state changes receive richer records and longer retention. Routine read queries receive shorter, security-focused treatment. Periodic Merkle commitments can cover many events without publishing or individually timestamping every record. Shared standards can reduce custom integration across RIRs.

The alternative also costs money. When evidence is weak, staff spend weeks reconciling emails and backups. Members commission experts. Courts face conflicting screenshots. Restorations are delayed because no one knows which transaction to trust. Governance debate becomes accusation rather than correction. The institution pays through legal expense and lost legitimacy even if the logging budget appears low.

Boards should evaluate the expected loss from irreconstructable critical events, not compare storage cost with zero. They can fund controls in stages and publish residual risk. Insurance or external assurance may require evidence quality and can help price the exposure.

The most expensive promise is false completeness. A registry that markets every log as immutable and then discovers an unrecorded staff path creates more liability than one that accurately states coverage and improves it. Cost discipline begins with honest scope.

Boards should receive evidence-health indicators

Registry boards rarely need raw events. They do need to know whether the institution can account for consequential changes. Evidence health belongs alongside service availability, security incidents and financial control.

A board dashboard can report critical event classes covered, reconstruction samples passed, external commitment intervals completed, sequence gaps, privileged exceptions, retention failures, open preservation holds, evidence requests and response performance. It should identify material incidents where attribution or authority could not be established.

The board should commission independent testing and ensure the assessor can reach systems controlled by staff with the greatest power. Management should not define away emergency consoles, restoration environments or legacy paths. Exceptions need owners and deadlines. Repeated failures should affect risk appetite and executive accountability.

Governance also covers access. Directors should know who can order disclosure, suspend retention, rotate evidence keys or authorize silent privileged action. Conflict rules matter when a complaint concerns senior staff or the board itself. An external reviewer or committee may need temporary authority.

Public reporting can summarize assurance and remediation without exposing member data. Members should see that the board asked whether transfers and recoveries are reconstructable, not merely whether an audit was completed.

Logs are institutional memory under technical control. Board oversight makes that memory answerable to the community whose rights it records. Without oversight, a strong cryptographic design can remain inaccessible precisely when governance needs it.

A record becomes evidence only through accountable custody

Registry logs can answer who did what and when, but only if “who,” “did” and “when” are separately designed. The immediate principal must connect to historical human or service authority. The act must preserve request, approval, before-and-after state and execution. Time must distinguish receipt, decision, commit and public effect. Recovery must append rather than erase.

Cryptography then protects the account. Hash chains, signed roots, trusted timestamps and external witnesses can make later interference detectable. They do not certify truth. Independent review, customer evidence, policy context and candid uncertainty remain necessary. Privacy requires tiered access, not evidentiary amnesia.

Public WHOIS and RDAP history will continue to serve a vital operational role. RIPE Database versions and ARIN WhoWas demonstrate the value of preserving visible change. Their limits should motivate a stronger protected layer rather than criticism for not being something they never claimed to be.

The enforceable right is straightforward: when a registry changes a high-value record, it should be able to show the authority and event chain to an entitled reviewer; when an incident threatens that chain, it should preserve it; when evidence is missing, the gap should have a consequence; and when privacy restricts disclosure, an independent path should remain.

Authority over scarce number resources cannot rest on a current screen alone. A legitimate registry keeps a history that can survive outage, staff turnover, institutional conflict and court scrutiny. The record becomes evidence not because the registry calls it authoritative, but because its custody, limits and consistency can be tested outside the moment of trust.

Sources